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Abstract 

Objects  model  the  world,  and  state  is  fundamental  to  a  faithful  modeling.  Engineers  use  state  machines  to 
understand  and  reason  about  state  transitions,  but  programming  languages  provide  little  support  for  building 
software  based  on  state  abstractions.  We  propose  Plaid,  a  language  in  which  objects  are  modeled  not  just 
in  terms  of  classes,  but  in  terms  of  changing  abstract  states.  Each  state  may  have  its  own  representation, 
as  well  as  methods  that  may  transition  the  object  into  a  new  state.  A  formal  model  precisely  defines  the 
semantics  of  core  Plaid  constructs  such  as  state  transition  and  trait-like  state  composition.  We  evaluate  Plaid 
through  a  series  of  examples  taken  from  the  Plaid  compiler  and  the  standard  libraries  of  Smalltalk  and  Java. 
These  examples  show  how  Plaid  can  more  closely  model  state -based  designs,  enhancing  understandability, 
enhancing  dynamic  error  checking,  and  providing  reuse  benefits. 
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1  Introduction 


Object-oriented  programming  provides  a  rich  environment  for  modeling  real-world  and  conceptual  objects 
within  the  computer.  Fields  capture  attributes  of  objects,  methods  capture  their  behavior,  and  subtyping  cap¬ 
tures  specialization  relationships  among  objects.  A  key  element  missing  from  object-oriented  programming 
languages,  however,  is  abstract  states  and  conceptual  state  change.  State  change  is  pervasive  in  the  natural 
world;  as  a  dramatic  example,  consider  the  state  transition  from  egg,  to  caterpillar,  to  pupae,  to  butterfly. 
Modeling  systems  with  abstract  states  and  transitions  between  them  is  also  common  in  many  engineering 
disciplines. 

In  computer  science,  state  machines  are  important  modeling  concepts  in  the  UML.  Abstract  states  are 
also  a  critical,  though  often  implicit,  part  of  many  library  APIs — and  any  client  using  that  API  must  be  aware 
of  those  states  to  use  the  API  correctly.  For  example,  a  file  may  be  in  the  open  or  closed  state.  In  the  open 
state,  one  may  read  or  write  to  a  file,  or  one  may  close  it,  which  causes  a  state  transition  to  the  closed  state. 
In  the  closed  state,  the  only  permitted  operation  is  to  (re-)open  the  file. 

Files  provide  a  simple  example  of  abstract  states,  but  there  are  many  more.  Streams  may  be  open  or  closed, 
iterators  may  have  elements  available  or  not,  collections  may  be  empty  or  not,  and  even  lowly  exceptions  can 
have  their  cause  set,  or  not1.  State  spaces  may  be  complex:  In  Re  suit  Set  from  the  Java  JDBC  library,  we 
found  33  unique  states  dealing  with  different  combinations  of  openness,  direction,  random  access,  insertions, 
etc  [7].  States  arc  also  common:  a  recent  study  of  protocols  in  Java  suggests  that  almost  three  times  as  many 
types  define  protocols  as  define  type  parameters  [3].  They  also  cause  significant  pain:  for  instance,  in  a 
study  of  problems  developers  experienced  when  using  the  ASP.NET  framework,  3/4  of  the  issues  identified 
involved  temporal  constraints  such  as  the  state  of  the  framework  in  various  callback  functions  [16].  All  this 
raises  a  natural  question:  why  not  support  abstract  states  in  programming  languages? 

We  previously  proposed  Typestate-Oriented  Programming  as  a  new  programming  paradigm  in  which 
programs  are  made  up  of  dynamically  created  objects,  each  object  has  a  typestate  that  is  changeable,  and 
each  typestate  has  an  interface,  representation,  and  behavior  [2].  The  term  typestate  refers  to  a  static  abstract 
state  checking  methodology  proposed  by  Strom  and  Yemini  [25] ;  this  paper  focuses  on  a  dynamically-typed 
setting,  and  so  we  will  use  the  terms  (abstract)  state  and  protocol  in  place  of  typestate  to  avoid  confusion. 

A  programming  language  with  abstract  states  can  have  many  benefits.  First,  in  the  case  of  stateful 
abstractions,  the  code  will  more  clearly  reflect  the  intended  design.  This  in  turn  will  make  state  constraints 
more  salient  to  developers  who  need  to  be  aware  of  them.  If  state  constraints  are  implicitly  enforced  by  the 
object  model,  there  is  no  need  to  code  up  explicit  checks;  thus  code  implementing  states  can  be  more  concise. 
Explicit  state  models  raise  the  level  of  error  messages;  instead  of  (perhaps)  silently  corrupting  a  data  structure 
when  an  inappropriate  method  is  called,  the  runtime  can  signal  an  error  that  that  method  is  unavailable  in  the 
current  state.  Finally,  explicit  modeling  of  states  also  exposes  new  concepts  for  widespread  reuse;  candidates 
may  include  open/closed  resources  or  positioning  (beginning,  middle,  end)  of  streams. 

Contribution.  The  contribution  of  this  paper  is  the  concrete  design  and  evaluation  of  Plaid,  an  object-oriented 
programming  language  that  incorporates  first-class  state  change  as  well  as  trait-like  state  composition.  Plaid 
has  been  implemented,  and  has  proven  effective  for  writing  a  diverse  set  of  small  and  medium-sized  (up  to 
lOkLOC)  programs,  including  a  self-hosted  compiler.  For  the  puiposes  of  this  paper,  Plaid  is  dynamically 
typed,  though  there  arc  plans  to  add  a  gradual  type  system  following  recent  work  on  gradual  typestates  [28]. 

The  most  interesting  aspects  of  Plaid's  design  come  from  the  intersection  of  state  change  with  support 
for  a  trait-like  model  of  composition  [12].  Central  goals  of  the  language  design  include  supporting  the 

*E.g.  in  Java,  the  cause  of  an  exception  can  only  be  set  once. 
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primary  state  modeling  constructs  from  statecharts  [14],  as  well  as  flexible  code  reuse.  Our  design  includes  a 
hierarchical  state  space,  so  that  the  open  state  of  a  stream  can  be  refined  into  within  and  eof  substates 
indicating  whether  there  is  data  left  to  be  processed.  Handling  real  designs  in  a  modular  way  requires  support 
for  multi-dimensional  state  spaces,  as  in  and-states  from  [14];  an  example  is  a  separate  dimension  of  a 
stream’s  state  indicating  whether  the  stream  has  been  marked  with  a  location  or  not.  Modularity  further 
requires  reasoning  about  dimensions  separately;  for  example,  the  mark  ( )  method  should  affect  the  marked 
state  dimension  but  it  should  not  affect  whether  the  stream  is  at  eof.  Dimensions  also  delineate  natural 
points  of  reuse;  we  would  like  to  specify  them  separately  and  combine  them  using  a  trait-like  composition 
operator. 

We  position  Plaid  relative  to  earlier  work  in  the  next  section.  Plaid's  design  is  described  by  example  in 
section  3.  This  section  validates  our  design,  using  a  number  of  carefully  chosen  examples  to  concretely  illus¬ 
trate  how  Plaid  provides  the  potential  benefits  described  above.  We  also  discuss  our  prototype  implementation 
of  Plaid,  targeting  the  JVM. 

In  order  to  be  precise  about  Plaid's  semantics,  Section  4  provides  a  formal  model  that  includes  the 
semantics  of  all  of  Plaid’s  major  features.  Section  5  describes  how  the  surface  Plaid  language  is  elaborated 
into  the  core  formal  model.  The  paper  concludes  with  a  discussion  of  ongoing  work  on  Plaid,  together 
with  an  argument  that  the  concrete  benefits  validated  by  example  lead  to  higher-level  benefits  in  software 
development  and  evolution. 

2  Background  and  Related  Work 

Plaid’s  state  constructs  are  inspired  and  guided  by  state  modeling  approaches  such  as  Harel’s  statecharts  [14]. 
Other  modeling  approaches  include  Pernici’s  Objects  with  Roles  Model  [20],  which  models  objects  using  a 
set  of  roles,  each  of  which  can  be  in  one  of  several  abstract  states. 

Strom  and  Yemini  proposed  typestate  as  a  compiler-checkable  abstraction  of  the  states  of  a  data  struc¬ 
ture  [25].  The  Fugue  system  was  the  first  to  integrate  typestates  with  an  object-oriented  programming 
language  [10].  Bierhoff  et  al.  later  observed  that  the  complexity  of  protocols  such  as  the  one  defined  by  the 
JDBC  ResultSet  interface  requires  rich  state  modeling  constructs  like  those  proposed  by  Harel  [7].  This  paper 
considers  a  dynamically-typed  setting,  so  we  do  not  discuss  static  checkers  further. 

State-dependent  behavior  can  be  encoded  using  the  State  design  pattern  [13].  However,  this  pattern  is 
less  direct  than  the  language  support  we  propose,  and  it  does  not  help  with  ensuring  that  a  client  only  uses 
operations  that  are  available  in  the  current  state. 

Dynamic  languages  such  as  Self  [27]  provide  the  ability  to  add  and  remove  methods,  as  supported  by 
Plaid's  state  change  operator.  Changing  a  delegation  slot  in  Self  can  also  be  used  to  simulate  state  change, 
as  can  the  become  method  in  Smalltalk  [18].  We  believe  that  Plaid's  more  structured  and  more  declarative 
constructs  for  state  modeling  have  advantages  in  terms  of  error  checking,  succinctness,  and  clear  expression 
of  design  compared  to  these  encodings.  Plaid’s  prototype-based  object  model  is  also  inspired  by  Self’s. 

Prior  State-Based  Languages.  The  Actor  model  [15]  treats  states  in  a  first-class  way,  using  the  current  state 
of  an  actor  to  define  the  response  to  messages  in  a  concurrent  setting. 

Taivalsaari  extended  class-based  languages  with  explicit  definitions  of  logical  states  (modes),  each  with 
its  own  set  of  operations  and  corresponding  implementations  [26].  Plaid’s  object  model  differs  in  providing 
explicit  state  transitions  (rather  than  implicit  ones  determined  by  fields)  and  in  allowing  different  fields  in 
different  states. 


2 


The  Ferret  language  [8]  provides  multiple  classification,  in  which  objects  can  be  classified  in  one  of 
several  states  in  each  of  multiple  dimensions.  Ferret  attaches  dimensions  to  classes,  not  other  states,  so 
dimensions  cannot  come  and  go  with  state  changes  (unlike  in  Plaid  and  Statecharts). 

A  number  of  CAD  tools  such  as  iLogic  Rhapsody  or  IBM/Rational  Rose  Real-Time  support  a  program¬ 
ming  model  based  even  more  directly  on  Statecharts  [14];  such  models  benefit  from  many  rich  state  modeling 
features  but  lack  the  dynamism  of  object-oriented  systems.  Recently  Sterkin  proposed  embedding  the  princi¬ 
pal  features  of  Statecharts  as  a  library  within  Groovy,  providing  a  smoother  integration  with  objects  [23].  Our 
approach  focuses  on  adding  states  to  object-oriented  languages,  rather  than  libraries. 

Other  researchers  have  explored  adding  a  class  change  primitive  to  statically-typed  languages  [11,  4,  6]. 
These  systems,  however,  do  not  support  the  richness  of  state  models  (e.g.  and-states)  as  provided  in  Statecharts 
and  in  Plaid. 

Schaerli  et  al.  proposed  traits  [12]  as  a  composition  mechanism  that  avoids  some  of  the  semantic 
ambiguities  of  multiple  inheritance.  Schaerli’s  traits  did  not  have  fields,  but  Plaid  follows  prior  designs  [5] 
to  add  them.  Like  some  other  recent  work  [22,  9],  Plaid  does  not  have  the  flattening  property,  in  which  the 
composition  structure  of  traits  is  compiled  away  and  does  not  affect  the  semantics  of  the  resulting  program. 
We  lose  the  simplicity  of  flattening  but  gain  the  ability  to  model  structured  state  spaces  more  directly,  as 
described  below. 

An  initial  sketch  of  the  Plaid  language  design  was  presented  earlier  [2]  as  an  instance  of  the  Typestate- 
Oriented  Programming  paradigm.  While  we  recap  the  motivation  and  concept  of  the  language  from  this 
earlier  work,  that  paper  described  an  unimplemented  language,  and  neither  defined  the  language  semantics 
nor  investigated  the  modeling  of  complex  state  spaces,  which  are  the  key  contributions  of  this  paper.  In  an 
earlier  4-page  workshop  paper,  we  explored  the  need  for  a  modular  state  change  operator  that  affects  only 
one  dimension  of  state  change  at  a  time  [1];  this  paper  gives  the  semantics  for  a  concrete  solution  to  that 
problem.  Other  recent  work  has  begun  to  explore  a  gradual,  permission-based  type  system  for  Plaid  [28]. 

3  Language 

In  this  section  we  will  introduce  Plaid  by  example.  These  examples  serve  the  dual  purpose  of  explaining  the 
language  and  validating  the  concrete  benefits  of  Plaid. 

3.1  Basics  of  State  Change 

Object  protocols  arc  rules  dictating  the  ordering  of  method  calls  on  objects.  The  concrete  state  of  an  object 
with  a  protocol  can  be  abstracted  into  a  finite  number  of  abstract  states  and  the  object  transitions  dynamically 
between  these  abstract  states.  Therefore,  clients  must  be  aware  of  the  abstract  states  in  order  to  use  the  object 
correctly. 

Most  programming  languages  provide  no  direct  support  for  protocols.  Instead,  protocols  arc  encoded  in 
the  language  using  some  combination  of  the  state  design  pattern  [13],  conditional  tests  on  fields,  and  other 
indirect  mechanisms.  In  Plaid,  protocols  are  supported  directly  with  states,  which  are  like  classes  in  Java, 
with  the  crucial  distinction  that  an  object’s  state  changes  as  the  object  evolves. 

Consider  the  state  space  of  files,  the  canonical  protocol  example  [2],  shown  in  Figure  1.  Some  files  are 
open  and  some  are  closed.  We  close  an  open  file  by  calling  the  close  method  and  open  a  closed  file  by 
calling  the  open  method.  One  cannot  open  an  open  file  so  the  open  file  state  does  not  include  the  open 
method.  Similarly,  one  cannot  read  a  closed  file  so  the  closed  file  state  does  not  include  the  read  method. 
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Figure  1:  State  space  of  File. 
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state  File  { 
val  filename; 

} 

state  OpenFile  case  of  File  =  { 
val  filePtr; 
method  read()  {  ...  } 

method  close ()  {  this  <-  ClosedFile;  } 

} 

state  ClosedFile  case  of  File  { 

method  open ( )  {  this  <-  OpenFile;  } 

} 


Listing  1:  File  states  in  Plaid 


The  state  space  of  files  can  be  encoded  cleanly  in  Plaid  as  shown  in  Listing  1.  The  state  keyword  is 
used  to  define  a  state.  The  File  state  contains  the  fields  and  methods  that  are  common  between  open  and 
closed  files.  In  this  case,  only  the  filename  is  shared.  Fields  are  declared  with  the  val  keyword. 

OpenFile  and  ClosedFile  define  the  methods  and  fields  that  are  specific  to  open  and  closed  states. 
Both  are  substates  of  File.  Specialization  is  declared  with  the  case  of  keyword.  In  addition,  case  of 
implies  orthogonality:  files  can  either  be  open  or  closed,  not  both.  Methods  are  defined  with  the  method 
keyword.  Open  files  have  a  read  method,  a  file  pointer  field  which  is  presumably  used  by  the  read  method 
to  read  the  file,  and  a  close  method.  Closed  files  have  the  open  method. 

The  open  and  close  method  bodies  contain  the  most  novel  bit  of  syntax.  An  object  referred  to  by  a 
variable  x  can  be  changed  to  state  S  by  writing  x  <-  S.  In  the  open  method  we  transition  the  receiver, 
referred  to  as  in  Java  by  the  keyword  this,  to  the  open  state  by  writing  this  <-  OpenFile. 

An  example  file  client  is  shown  in  Listing  2.  The  readClosedFile  method  takes  a  file  as  an  argument, 
opens  it,  reads  from  it,  closes  it,  and  returns  the  value  read  from  the  file.  All  of  the  method  calls  are  valid  if 
a  closed  file  is  passed  to  the  method.  If  an  open  file  is  passed  instead  the  open  method  call  will  fail.  The 


1  method  readClosedFile (f)  { 

2  f . open  ( ) ; 

3  val  x  =  f . read ( ) ; 

4  f .close  () ; 

5  x ;  //return 

6  } 

Listing  2:  File  client  in  Plaid 
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f  Butterfly  > 


Figure  2:  Buttefly  life-cycle. 


library  writers  do  not  need  to  write  any  special  error  handling  code  to  handle  this  condition  like  they  would  in 
Java.  This  has  the  concrete  benefit  that  Plaid  code  for  the  equivalent  design  is  smaller. 

In  most  programming  languages,  fields  of  an  object  are  often  null  in  certain  abstract  states.  For  example, 
Java  files  might  contain  a  null  f  ilePtr  when  the  file  is  closed.  Null  pointers  are  a  frequent  cause  of  runtime 
errors  and  their  cause  can  be  difficult  to  diagnose.  For  these  reasons,  Tony  Hoare  recently  called  null  pointers 
a  “billion  dollar  mistake,”  and  we  have  not  repeated  this  mistake  in  Plaid. 

Plaid  objects  are  always  consistent:  in  other  languages  a  programmer  might  forget  to  check  the  state  before 
performing  an  operation  and  perform  the  operation  on  an  object  in  the  wrong  state.  Similarly,  the  operation 
might  fail,  but  with  a  less  specific  error  message.  For  example,  if  a  client  calls  the  read  method,  implemented 
in  Java  without  error  handling,  on  a  closed  file,  Java  might  throw  a  NullPointerException  for  a  null 
dereference  of  filePtr. 

3.2  State  Transtions 

The  file  state  space  is  a  complete  directed  graph,  every  pair  of  states  is  connected  in  both  directions  by  an  edge. 
Other  kinds  of  objects  have  incomplete  state  spaces.  Consider  the  life-cycle  of  a  butterfly,  which  is  illustrated 
by  the  state-space  in  Figure  2.  A  butterfly  egg  hatches  to  a  caterpillar,  but  it  cannot  ‘un-hatch’.  Similarly,  a 
butterfly  never  transitions  directly  from  a  caterpillar  to  an  imago,  it  always  transforms  to  a  chrysalis  first. 

To  preserve  the  integrity  of  incomplete  protocols,  only  the  method  receiver  (this),  can  be  the  target  of  a 
state  change  operation.  If  Plaid  did  not  have  this  restriction  it  would  be  trivial  for  programmers  to  inadvertently 
violate  a  protocol.  Consider:  val  x  =  new  Egg;  x<-Caterpillar;  x<-Egg.  This  illegal  Plaid  code 
violates  the  protocol  by  restoring  a  caterpillar  to  an  egg.  Instead,  in  legal  Plaid  code,  methods  defined  in  the 
butterfly  states  perform  all  of  the  state  transitions. 

3.3  Dimensions  of  State  Change 

Many  objects  in  the  real  world  are  not  as  simple  as  files  or  butterflies.  Some  objects  are  composed  of  multiple 
states,  particularly  when  objects  are  built  up  from  reusable  components.  These  components  may  change 
their  state  independently,  or  orthogonally.  For  example,  cars  have  both  gears  and  brakes  and  when  the  car 
shifts  gears  it  has  no  effect  on  the  brakes.  States  that  change  independently  are  in  different  dimensions.  State 
dimensions  in  programming  languages  were  introduced  in  [7]. 

More  concretely,  let  us  say  a  stream  is  in  state  unmarked  in  dimension  markable,  and  state  within  in 
dimension  position.  If  the  object  changes  to  state  marked,  also  in  dimension  markable,  it  will  lose  all  of 
the  fields  and  methods  defined  in  unmarked  (such  as  mark),  gain  those  in  marked  (such  as  reset),  and 
keep  those  in  within  (such  as  read). 

The  full  power  of  Plaid  comes  when  component  states  are  themselves  composed  of  multiple  states.  In 
such  a  setting  the  component  states  are  gained  and  lost  along  with  their  parents.  Many  of  this  kind  of  deep 
hierarchies  exist  in  the  wild  [3],  For  example,  in  the  Java  Database  Connectivity  library,  the  ResultSet 
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Figure  3:  ResultSet  state-chart. 


interface  is  composed  from  a  combination  of  33  states,  four  levels  of  nesting,  and  eight  dimensions.  A  slightly 
simplified  schematic  of  the  state  space  is  shown  in  Figure  3. 

The  features  of  the  language  just  described  correspond  directly  to  the  ‘hierarchical-states’,  ‘and-states’ 
and  ‘or-states’  proposed  by  Harel  in  his  seminal  state-chart  paper  [14].  Hierarchical-states  are  states  that  are 
composed  of  other  states.  And-states  are  states  that  both  must  be  present  in  an  object — separate  dimensions 
that  are  modeled  using  with  composition  in  Plaid.  Finally,  or-states  are  states  in  the  same  dimension,  and 
therefore  only  one  can  be  present  in  an  object — a  state  that  is  a  case  of  another  state.  These  features  are 
the  fundamental  building  blocks  of  the  Harel  state  chart  formalism  (which  forms  the  basis  for  UML  state 
diagrams),  and  are  naturally  encoded  in  Plaid  exactly  in  the  manner  we  just  described. 

In  the  ResultSet  diagram  (Figure  3),  or-states  arc  separated  by  white  space.  For  example,  Open  and 
Closed  are  states  in  one  dimension,  ForwardOnly  and  Scrollable  are  in  another.  Hierarchical-states 
are  indicated  by  nesting  of  the  state  rectangles.  For  example,  Scrolling  is  a  child  of  Open  and  Begin 
of  Scrolling.  The  names  of  states  with  children,  like  Open  appear  outside  the  state -rectangle,  and 
the  names  of  simple  states  without  children,  like  Inserted,  appear  inside  the  state -rectangle.  Finally, 
and-states  are  separated  into  orthogonal  regions  by  dotted  lines,  so  Direction  and  Status  are  and-states. 

There  is  a  natural  one-to-one  correspondence  between  the  state  rectangles  in  the  diagram  and  the  state 
declarations  in  Plaid  code.  A  subset  of  the  declarations  for  ResultSet  states  arc  shown  in  Listing  3.  The 
or-states  are  all  declared  to  be  cases  of  their  dimensions.  For  example,  ForwardOnly  and  Scrollable 
are  cases  of  the  Direction  dimension.  The  dimensions  are  themselves  states  in  which  case  their  or-states 
will  inherit  all  of  the  dimension’s  fields  and  members.  Sometimes,  however  the  state  is  a  pure  dimension  and 
does  not  contain  members.  In  this  case  the  state  only  serves  to  ensure  that  or-states  do  not  appeal-  together. 
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state  Open  case  of  ResultSet  = 

Direction  with  Status  with  Action; 
state  Direction; 

state  ForwardOnly  case  of  Direction; 
state  Scrollable  case  of  Direction; 
state  Status; 

state  Readonly  case  of  Status; 
state  Updatable  case  of  Status; 
state  Action; 

state  Scrolling  case  of  Action; 
state  Inserting  case  of  Action; 
state  Insert  case  of  Inserting; 
state  Inserted  case  of  Inserting; 

val  myResultSet  =  new  Open  @  ForwardOnly 
with  Updatable  with  Insert; 


Listing  3:  ResultSet  state  declarations  and  instantiation 


The  Open  state  contains  several  nested  and-states.  Therefore,  Open  is  declared  as  a  composition 
of  the  three  nested  dimensions  using  the  with  operator.  This  encoding  captures  the  invariant  that  any 
object  in  the  Open  state  is  also  in  the  Direction,  Status,  and  Action  states.  Often  ResultSet 
objects  will  be  instantiated  with  children  of  the  three  dimensions  Direction,  Status,  and  Action.  For 
example,  at  the  end  of  Figure  3,  myResultSet  is  assigned  to  an  open  object  in  the  ForwardOnly,  Updatable 
and  Insert  states.  This  object  will  contain  the  methods  and  fields  from  Insert,  Inserting,  Action, 
Updatable,  Status,  Forwardonly,  Direction,  Open  and  ResultSet.  If  we  were  to  change  the 
state  of  myResultSet  to  Inserted  by  calling  a  method  that  does  so  for  us  the  object  would  have  all  of 
the  same  states,  with  the  exception  that  Insert  will  be  replaced  with  Inserted.  This  is  because  Insert 
and  Inserted  are  or-states  from  the  same  dimension.  When  we  close  the  object,  we  lose  not  only  the 
Open  state  but  all  of  the  states  nested  inside  it.  We  are  left  only  with  Closed  and  ResultSet. 

The  @  operator  is  syntactic  sugar  that  allows  an  initializer  to  conveniently  choose  nested  sub-states.  The 
myResultSet  initializer  in  Figure  3  is  desugared  to  the  following  code: 

1 

2 
3 

First,  an  Open  object  is  created.  Then  the  object  is  changed  to  substates  of  the  three  dimensions  using  the 
state  change  operator.  Notice  that  the  left  side  of  the  state-change  operator  is  not  this  in  the  de-sugared 
code  which  violates  the  restriction  discussed  in  Section  3.2.  This  is  okay,  because  the  restriction  only  applies 
to  Plaid  source  which  in  this  case  uses  the  @  operator. 

In  this  example  the  reader  can  see  that  the  Plaid  code  closely  reflects  the  design  embodied  in  the  state 
chart.  The  stateful  design  is  salient  in  the  state  declarations.  Since  the  mapping  between  the  code  and  the 
state  chart  is  so  clear,  a  programmer  reading  the  state  declarations  can  easily  understand  the  relationship 
between  the  states.  In  fact,  our  group  has  built  a  tool  to  automatically  extract  a  state  chart  from  Plural2,  a 
typestate  checker  for  annotated  Java  code,  and  although  we  have  not  built  such  a  tool  for  Plaid,  the  language 

2  http :  //code  .google  .com/p/plurali  sm/ 


var  myResultSet  =  new  Open; 
myResultSet  <-  ForwardOnly  with  Updatable 
with  Insert; 
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state  Position  { 

state  notEndState  =  NotEnd; 
state  endState  =  End; 
method  setToEndO; 
method  setToStart ()  ; 
val  vector,  minPos,  maxPos; 
var  currPos; 


state  NotEnd  case  of  Position  { 
method  setToEnd()  { 

this. currPos  =  this. maxPos; 

this  <-  this . endState; 

} 

method  setToStart ()  { 

this. currPos  =  this. minPos; 

} 

method  nextPosit ion  ( )  { 

this . currPos++; 

if  (this . currPos  >=  this. maxPos)  { 
this  <-  this . endState; 

) 

) 

} 

state  End  case  of  Position  { 
method  setToEndO  {  /*  no  op  */} 
method  setToStart  ()  { 

this. currPos  =  this. minPos; 
this  <-  this . notEndState; 

} 


Listing  4:  Position  code. 


design  clearly  enables  it.  A  second  potential  benefit  is  that  code  for  each  state  can  be  given  separately  in  the 
appropriate  state  declaration,  potentially  permitting  more  fine-grained  reuse  across  multiple  implementations 
of  the  ResultSet  interface. 

3.4  State  members 

As  we  mentioned  in  the  introduction.  Plaid  combines  state  change  with  support  for  a  trait-like  model  of 
composition  [12].  We  now  illustrate  a  particularly  novel  feature  of  Plaid,  namely,  state  members.  States  can 
have  other  states  as  members,  and  these  state  members  can  be  customized  upon  composition.  This  allows  for 
consistent  state  update,  in  presence  of  composite  states. 

We  illustrate  state  members  and  their  benefits  through  a  Plaid  version  of  a  ReadWriteStream  adapted 
from  [12],  which  is  in  turn  adapted  from  the  Smalltalk  standard  library.  The  Plaid  components  mirror  the  trait 
components,  except  in  our  version  the  methods  of  a  single  trait  arc  sometimes  divided  across  multiple  states. 
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state  Reader  {  } 

state  Reading  case  of  Reader  { 
method  read()  { 

val  ret  =  this . vector . get (this . currPos ) ; 
this . nextPosition ( ) ; 

} 

} 

state  ReadEnd  case  of  Reader  {  } 

state  ReadStream  =  Position  { 

val  notEndState  =  Reading  with  NotEnd; 
val  endState  =  ReadEnd  with  End; 

}  with  Reader; 

Listing  5:  ReadStream  code. 


The  Position  state  represents  the  position  of  the  pointer  into  a  stream  or  collection.  It  has  a  very 
limited  interface  which  therefore  makes  it  easy  to  reuse  throughout  an  input-output  and  collection  library. 
The  code  for  Position  is  shown  in  Listing  4.  Position  declares  two  abstract  methods  for  setting  the 
position,  a  reference  to  the  underlying  collection  (vector),  constant  fields  for  minimum  and  maximum 
position,  and  a  variable  field  for  the  current  position3. 

Interestingly,  Position  contains  two  state  members,  one  for  the  end-state  and  one  for  the  not-end-state. 
The  state  members  are  initialized  to  NotEnd  and  End,  also  defined  in  Listing  4.  These  states  are  sub-states  of 
Position,  as  specified  by  the  case  of  declarations.  They  implement  the  abstract  methods  of  Position. 
In  addition,  NotEnd  has  an  additional  method  nextPosition,  reflecting  the  fact  that  in  that  state,  the 
position  can  be  advanced.  This  method  increments  the  current  position,  tests  if  the  current  position  is  at  or 
past  the  maximum  position,  and  transitions  the  receiver  to  the  end  state  if  the  position  is  at  the  end.  Similarly, 
setToStart  in  End  transitions  the  receiver  back  to  the  not-end  state. 

The  crucial  part  in  this  example  is  that  the  state  transitions  do  not  explicitly  reference  a  specific  target 
state,  but  rather  reference  the  state  members  of  Position.  For  instance,  nextPosition  in  NotEnd 
transitions  this  to  this  .  endState,  not  End.  This  allows  for  consistent  and  flexible  reuse,  composition, 
and  extension  of  states,  as  illustrated  hereafter. 

Consider  the  code  for  a  ReadStream,  as  shown  in  Listing  5.  The  ReadStream  definition  includes  a 
pure  dimension,  Reader.  This  dimension  has  two  children  Reading  and  ReadEnd,  which  correspond  to 
the  ReadStream  in  the  not-end-state  and  the  end-state,  respectively.  In  the  not-end-state,  the  ReadStream 
can  read,  and  therefore  Reading  defines  the  read  method.  This  method  reads  from  the  underlying 
collection  at  the  current  position  and  advances  the  position. 

The  ReadStream  is  composed  from  the  two  dimensions  Position  and  Reader  .  ReadStream 
specializes  NotEnd  by  overriding  the  two  state  members  in  P  os  it  ion.  The  state  members  in  ReadStream 
are  composed  from  two  states,  one  from  each  dimension  of  ReadStream.  Therefore,  when  the  methods  in 
Position  and  its  children  change  state,  they  will  change  both  dimensions  of  ReadStream.  For  example, 
when  nextPosition  advances  the  stream  to  the  end,  the  ReadStream  object  composed  of  Reading 
with  NotEnd  will  change  to  a  ReadEnd  with  End. 

3  Abstract  methods  are  indicated  by  eliding  the  method  body;  constant  fields  are  declared  with  val,  and  variable  fields  with  var. 
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1  state  ReadWriteStream  =  Position  { 

2  val  notEndState  = 

3  Writing  with  Reading  with  NotEnd; 

4  val  endState  = 

5  WriteEnd  with  ReadEnd  with  End; 

6  }  with  Reader  with  Writer; 

Listing  6:  ReadWriteStream  code. 


To  Initialize  a  ReadStream  we  need  to  specify  the  starting  and-states  like  for  ResultSet.  The  code 
to  create  a  ReadStream  x  that  is  not  at  the  end  is  va  1  x  =  new  ReadStream  @  ReadEnd  with 
NotEnd; .  Here  again,  we  use  the  @  operator  to  begin  the  ReadStream  in  particular  substates  of  the 
and-states  nested  in  ReadStream. 

Since  the  Reader  dimension  has  the  same  structure  as  the  Position  dimension  it  is  natural  for 
transitions  in  Position  to  change  Reader  as  well.  In  this  example,  there  is  no  code  in  the  Reader  states 
that  enacts  the  state  change.  Instead,  the  Reader  dimension  relies  on  the  Position  dimension  to  perform 
state  changes.  The  state  members  in  this  example  allow  for  this  kind  of  dimensional  reuse  without  extensive 
glue  code4.  The  only  code  required  to  required  to  reuse  the  dimension  is  the  specialization  of  state  members 
in  ReadStream. 

We  now  illustrate  a  further  step  of  consistent  composition  of  states  with  the  definition  of  ReadWriteStream 
in  Listing  6.  The  definition  uses  a  new  dimension.  Writer,  with  two  substates  Writing  and  WriteEnd, 
defined  in  the  same  manner  as  the  Reader  states. 

This  ReadWriteStream  reuses  code  from  all  three  dimensions  with  very  little  effort.  The  ReadWriteStream 
is  the  natural  extension  of  ReadStream.  The  state  members  are  composed  from  all  three  dimensions.  The 
state  transitions  in  a  ReadWriteStream  object  will  change  all  three  dimension  at  once. 

The  ReadWriteStream  example  demonstrates  both  the  power  of  a  trait-like  composition  model  and 
its  novel  extension  to  states.  We  reuse  ReadStream  and  WriteStream  with  little  effort,  as  we  could 
achieve  in  a  language  with  traits.  In  addition,  we  have  a  new  unit  of  reuse,  the  Position  dimension,  which 
is  shared  with  two  other  dimensions.  This  reuse  eliminates  duplicate  code,  and  helps  avoid  bugs.  Both 
the  Reader  and  Writer  of  a  ReadWriteStream  are  in  the  end-state  or  not-end  state.  Because  the 
dimension  is  reused  we  can  guarantee  that  no  programmer  will  err  and  end  up  with  an  object  in  an  inconsistent 
state  like  WriteEnd  with  Reading. 

One  important  note  is  that  the  Writer  and  Reader  contain  no  members  in  common,  and  therefore  no 
conflict  arises.  Plaid  requires  explicit  conflict  resolution  at  the  point  of  composition.  This  conflict  resolution 
will  be  described  in  Section  4.2. 

3.5  Validation 

The  introduction  claims  four  concrete  benefits  of  Plaid:  code  closely  reflects  design,  programs  are  concise, 
error  checking  is  implicit,  and  new  opportunities  for  reuse.  These  benefits  were  illustrated  in  the  examples 
in  this  section  and  they  were  discussed  while  describing  the  examples.  We  summarize  the  case  here  for 
emphasis.  We  then  reflect  on  our  experience  writing  mid-sized  programs  in  Plaid,  in  diverse  domains. 

4State  members  also  have  a  more  traditional  purposes.  State  members,  like  all  states,  can  be  used  to  create  objects.  They  allow  us 
to  encode  ML-style  structures  and  functors.  These  abstraction  mechanisms  can  be  very  powerful,  especially  in  a  typed  version  of 
Plaid.  However,  these  purposes  are  not  novel  to  Plaid  so  we  do  not  focus  on  these  here. 
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Project 

Lines  of  Code 

#  Files 

CodeGenerator 

1205 

24 

AeminiumCodeGen 

2610 

8 

Typechecker 

4196 

55 

ASTtranslator 

9506 

107 

PlaidApps 

528 

21 

Standard  Library 

372 

18 

TestCompiler 

2811 

96 

TestTypechecker 

363 

9 

Total 

21591 

338 

Table  1:  Plaid  code  written  for  eight  projects. 


3.5.1  Concrete  benefits 

Code  reflects  design.  Designs  with  stateful  abstractions  are  clearly  reflected  in  Plaid  code.  This  is  clear  in 
of  all  three  examples  in  this  section.  The  implementation  of  the  file,  result  set,  and  read-write  streams  all 
match  their  designs.  Arbitrarily  complex  state-charts  can  be  encoded  in  Plaid  with  the  simple  rules  described 
alongside  the  result  set  example.  Each  abstract  state  maps  to  its  own  state  in  code,  so  the  design  of  the 
abstraction  and  its  protocol  as  a  whole  is  highly  salient  in  the  code. 

Concise  programs.  Since  state  constraints  are  implicitly  enforced  by  the  object  model,  none  of  our  examples 
included  any  error  checking  code.  The  implementation  arc  therefore  smaller. 

Error  Prevention.  Plaid’s  explicit  state  models  make  error  checking  more  consistent,  because  the  pro¬ 
grammer  cannot  forget  to  check  state  constraints  when  a  method  is  called.  The  level  of  abstraction  of  error 
messages  is  also  thereby  raised:  when  an  inappropriate  method  is  called,  instead  of  triggering  an  internal 
run-time  exception  such  as  a  null  pointer,  or  (what  is  worse)  silently  corrupting  data,  the  runtime  can  signal 
an  error  that  a  particular  method  is  unavailable  in  the  current  state.  Also,  we  have  shown  how  state  members 
can  be  used  to  enforce  consistency  of  multiple  dimensions  of  state  at  once. 

Reuse.  Plaid  provides  new  reuse  opportunities.  Some  state  machines  arc  used  in  many  objects.  For  instance, 
the  Position  dimension  was  reused  in  both  read  and  write  streams,  and  it  could  also  be  reused  in  many  10 
and  Collection  libraries.  Open  and  closed  resources  like  the  File  and  ResultSet  arc  also  very  common. 

3.5.2  Applicability  to  diverse  domains 

In  order  to  gain  practical  experience  with  the  language  and  experiment  with  typestate-oriented  programming 
beyond  small  examples,  we  have  written  several  mid-sized  programs  in  Plaid.  These  programs  further 
demonstrate  the  expressiveness  of  Plaid  in  a  diverse  set  of  domains  including  compilation,  input-output, 
GUIs,  and  web.  They  are  all  available  for  download  from  the  Plaid  repository5.  In  total,  we  have  written 
22KFOC  across  338  files.  A  breakdown  of  our  implementations  is  in  Table  1.  We  call  out  items  of  particular 
interest  here. 

3http://code.google.com/p/plaid-lang/ 
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Compiler.  Plaid  is  self-hosting;  the  CodeGenerator  project  compiles  Plaid  code  into  Java  source.  Plaid  code 
can  easily  use  Java  libraries  and  many  of  our  examples  are  implemented  that  way.  In  a  sister  project  [24],  we 
have  implemented  a  separate  compiler  for  parallel-by-default  code,  which  is  the  AeminiumCodeGen  project. 
We  arc  currently  working  on  a  Plaid  typechecker;  the  implementation  is  the  Typechecker  project.  All  these 
projects  arc  supported  by  AST  transformations  performed  by  the  ASTtranslator  project. 

GUI  Library.  GUI  libraries  often  impose  state  constraints  on  their  clients.  We  implemented  Plaid  wrappers 
for  a  few  key  Java  Swing  classes,  including  Window,  Pane,  and  Canvas  abstractions.  We  use  states  to  enforce 
proper  initialization  of  these  abstractions.  In  particular,  windows  should  have  some  contents  added,  otherwise 
they  are  created  with  size  zero.  Furthermore,  windows  are  Hidden  until  show  ( )  is  called,  then  they  become 
Visible.  Panes  should  also  have  contents  added.  Both  panes  and  canvases  must  be  assigned  a  parent 
window,  and  canvases  should  be  given  a  preferred  size.  Our  library  is  not  comprehensive,  but  it  is  sufficient 
to  build  demonstration  applications — in  our  case,  a  Turing  machine  that  uses  Plaid’s  states  to  represent  the 
finite  state  control,  the  marks  on  the  tape,  and  the  illusion  of  an  infinite  tape.  Both  the  windowing  library  and 
Turing  demonstration  application  arc  in  the  PlaidApps  project. 

Miscellaneous  The  Plaidapps  project  includes  the  examples  discussed  earlier  and  a  small  web  server  and 
workflow  engine.  The  Plaid  standard  library  includes  integers,  rationals,  strings,  options,  and  standard  control 
(e.g.  if)  and  looping  (e.g.  for,  while)  structures.  Finally,  two  testing  projects  include  a  number  of  smaller 
tests  and  examples. 

4  Semantics 

In  this  section  we  present  the  formal  definition  of  the  Plaid  language  and  give  it  a  precise  semantics.  At 
its  core,  Plaid  is  an  object  system  with  first-class  generators  and  functions.  Individual  generators  can  be 
combined  and  specialized  using  composition  and  operators  inspired  by  traits  [12],  instantiated  to  create 
objects,  or  used  to  specify  the  abstract  state  the  object  should  change  to.  We  start  by  describing  the  syntax 
and  object  model  of  a  core  language,  which  is  intended  to  be  simpler  than  Plaid  source  code  yet  be  capable  of 
representing  all  of  the  major  semantic  elements  of  Plaid.  Then  we  discuss  the  execution  semantics  of  the  core 
language. 

4.1  Core  Syntax 

The  syntax  of  the  internal  representation  of  Plaid  is  given  in  Figure  4.  In  these  definitions,  x  ranges  over 
bound  variables,  while  members  of  objects  are  represented  by  /,  m,  and  s,  which  respectively  range  over 
fields,  methods,  and  state  members.  We  use  n  to  represent  any  kind  of  object  members  when  we  do  not 
distinguish  between  them.  Abstract  states  are  represented  using  tags  which  are  generated  as  needed.  We  will 
introduce  each  syntactic  category  in  turn,  describing  its  purpose  and  motivations. 

4.1.1  Expression  Syntax 

Plaid  contains  the  standard  expressions  found  in  object  systems,  including  object  creation  through  new, 
field  selection,  and  method  calls.  Because  Plaid  also  has  first-class  functions,  we  include  standard  function 
definition  and  application  as  well.  For  sequential  expressions,  we  include  let  bindings  and  bound  variable 
references. 
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Obj  Val 

OV 

:=  mv  |  dv  |  mv  x  ov  |  dv  v  ov 

Dim  Val 

dv 

:=  tag{ov}  tag{ov}  <:  dv 

Mbr  Val 

mv 

:=  method  m(x){e}  \ 
val  n  =  v 

Obj  Exp 

oe 

:=  me  v  oe  de  x  oe  ex  oe 
me  |  de  |  e 

Dim  Exp 

de 

:=  dv  tag{oe }  tag{oe}  <:  de 
e  |  e{to} 

Mbr  Exp 

me 

:=  mv  val  /  >  x  =  e  1 

recstatejval  s  >  x  =  proto  sd} 

State  Decl 

sd 

:=  freshtagjoe}  c  de  \ 
freshtagjoe}  |  oe 

Trait  Op 

to  : 

:=  \n  |  n  n'  |  me  (tagOf  e).me 

Val 

V 

:=  t  |  ov\  proto  oe  |  fn(x)  =>  e 

Exp 

e 

:=  x  |  v  let  x  =  e  in  e  | 
e(e)  |  e.m(e)  |  e.n  | 
e  v-  e  |  e  «—  e  |  new  e  | 
match(e){c}  | 
freeze  e  recstate{fmJ}#l 

Case 

c  : 

:=  case(tagOf  e)  {e}  default  {e} 

Figure  4:  Internal  Syntax 


The  rest  of  the  expression  forms  are  related  to  Plaid’s  encoding  of  abstract  states  and  the  transitions 
between  them: 

Changing  state.  The  Plaid  core  has  two  state  change  operators.  c-  represents  a  state  update  and  only 
removes  portions  of  the  receiving  object  that  arc  mutually  exclusive  with  the  incoming  states.  For  complete¬ 
ness  and  flexibility,  Plaid  also  includes  a  state  replacement  operator,  which  wipes  the  receiving  object 
clean  before  adding  the  incoming  states,  much  like  an  in-place  new  operation.  One  could  imagine  using  this 
operator  in  a  situation  where  an  object  needed  to  be  in  a  particular'  state  and  no  other  states.  This  cannot  be 
guaranteed  by  the  state  update  operator  because  state  update  leaves  dimensions  unrelated  to  the  updating 
state  alone. 

Unlike  the  source  language.  Plaid’s  core  does  not  require  the  target  of  a  state  change  operator  to  be  this. 
This  makes  the  core  simpler  and  more  flexible  since  the  restriction  can  be  enforced  at  the  source  level. 

proto  values.  First  class  instance  generators  are  provided  by  proto  expressions.  These  are  values  which  can 
be  stored  in  fields  and  passed  as  parameters.  During  a  well-formed  execution,  the  target  of  new  expressions 
and  the  right-hand  side  of  state  change  expressions  will  evaluate  to  a  proto  value.  This  is  because  they 
encapsulate  object  expressions,  oe,  which  are  uninitialized  objects.  The  state  change  and  new  expressions 
cause  the  initialization  steps  specified  by  the  object  expression  wrapped  in  the  proto  to  be  evaluated  for  use 
in  creating  a  new  object  or  changing  the  state  of  an  existing  one. 
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State  expressions.  To  allow  states  to  be  chosen  dynamically  at  runtime,  we  include  several  expression 
forms  that  can  evaluate  to  a  proto.  As  they  arc  values,  standard  deference  or  bound  variables  could  result  in 
proto  expressions.  Because  most  states  included  in  protocols  must  be  defined  with  (mutual)  recursion,  proto 
values  represented  source-declared  states  are  wrapped  into  a  recstate.  A  particular'  proto  can  be  selected 
from  the  recstate  as  from  a  standard  record. 

The  freeze  expression  is  a  more  novel  way  to  get  a  proto.  It  takes  the  object  and  wraps  it  up  in  a 
proto  allowing  new  instances  to  be  generated  from  it.  As  an  example  of  the  use  of  freeze,  consider  the 
myResultSet  value  defined  in  Listing  3.  Say  we  wanted  to  do  some  extra  initialization  of  the  ResultSet 
before  using  it  and  that  over  the  course  of  a  program  we  would  create  the  same  ResultSet  over  and  over. 
To  avoid  needing  to  do  the  same  initialization  repeatedly,  one  could  freeze  the  object  the  fully  initialized 
object  and  then  instantiated  it  each  time  a  new  ResultSet  of  this  form  was  needed,  freeze  has  already  been 
used  in  the  Plaid  compiler  to  more  cleanly  support  certain  initialization  paradigms,  such  as  the  transformation 
to  let-normal  form,  where  strings  of  let  bindings  must  be  concatenated  together. 

Matching  tags.  Finally,  the  match  construct  allows  pattern  matching  based  on  tags.  Each  case  tests  the 
target  object  against  the  tagOf  another  expression.  This  expression  is  expected  to  evaluate  to  a  proto  value 
with  a  single  outer  tag  which  is  grabbed  by  tagOf  and  compared  with  the  tags  of  the  target  object.  If  the 
object  contains  the  tag,  the  corresponding  case  is  executed.  Cases  are  evaluated  in  order. 

An  example  of  the  use  of  match  comes  from  the  Plaid  standard  library.  Plaid’s  syntax  does  not  include 
control  structures.  Instead,  if  and  while  are  encoded  as  functions  that  make  use  of  match.  The  states 
True  and  False  are  each  defined  as  a  case  of  Boolean.  Thus,  the  if  function  determines  whether  or 
not  to  evaluate  the  body  based  on  whether  the  object  returned  by  the  condition  matches  the  True  tag. 

4.1.2  Object  Value  Syntax 

Plaid  objects  are  collections  of  tags  representing  the  states  that  the  object  is  in  along  with  fields  and  methods 
that  provide  the  representation  and  operations  of  those  states.  In  order  to  implement  the  desired  semantics 
these  object  must  be  organized  to  formally  encode  the  relationships  between  tags  and  members  that  the 
semantics  depend  on.  In  particular,  we  need  to  represent  the  following  relationships  between  the  abstract 
states  that  the  tags  represent: 

1.  Superstates :  An  object  in  state,  S,  which  is  defined  to  be  a  case  of  a  superstate,  T,  must  also  be  in  state 
T.  For  instance,  an  object  in  the  NotEnd  state  defined  in  figure  4  is  also  in  the  Position  state. 

2.  Or-states :  Distinct  cases  of  a  given  state,  such  as  the  OpenFile  and  ClosedFile  case  of  File, 
cannot  exists  together  in  an  object. 

3.  And-states :  Both  objects  and  states  can  be  defined  as  a  composite  of  other  states.  For  example,  the 
Open  state  from  Listing  3  is  defined  in  terms  of  states  Direction,  Status,  and  Action.  Objects 
in  the  composite  state  are  considered  to  be  in  each  of  the  component  states  as  well. 

4.  Defining  states :  Members  must  be  associated  with  the  state  that  declares  them  so  that  they  can  be 
removed  from  an  object  when  their  defining  state  is  removed. 

To  formalize  these  relationships,  objects  values  are  organized  as  hierarchical  collections  of  dimensions,  which 
contain  tags  for  the  state  and  all  of  its  transitive  super  states,  and  members. 
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Object  values.  The  basic  component  of  an  object  is  an  object  value,  ov,  which  is  a  list  of  dimension 
values,  dv,  and  member  values,  mv.  They  are  used  to  represent  both  top-level  objects  and  the  dimensions 
and  members  that  define  a  given  state  (see  dimension  values  below).  The  v  operator  that  separates  each 
element  of  the  list  represents  composition.  Object  values  encode  and-states  by  allowing  two  dimensions  to 
coexist  together  inside  the  definition  of  a  state.  For  instance,  the  object  value  that  defines  a  ReadStream 
would  have  two  composed  dimensions,  one  for  the  Position  dimension,  and  the  other  for  the  Reader 
dimension. 

Dimension  values.  Dimension  values,  tag{ov}[<:  dv],  encode  the  structure  of  a  state  and  its  super  states. 
They  are  represented  by  a  tag,  tag,  which  is  a  unique  name  for  the  most  specialized  state  from  the  dimension. 
Associated  with  the  tag  is  an  object  value  which  represents  the  collection  of  members  that  the  state  defines 
along  with  any  other  dimensions  that  make  up  the  and-states  of  the  state.  A  dimension  value  may  optionally 
contain  another  dimension  value  encoding  the  superstate  relationship. 

By  containing  the  representation  of  a  given  states  superstates,  dimension  values  give  us  a  way  to  encode 
the  or-state  relationship  as  well.  Two  states  that  are  the  case  of  the  same  superstate  would  be  encoded  as 
separate  dimensions  with  the  same  state  at  the  root  of  the  dimension.  Because  the  tags  in  the  dimensions 
partially  overlap,  by  restricting  tags  to  appear  only  once  in  a  given  object  value,  we  can  ensure  that  no 
or-states  can  coexist  in  a  single  object. 

Concretely,  we  would  represent  an  instantiated  Open  state  from  Listing  3  as 

Open{Direction  v  Status  v  Action}  <:  ResultSet. 

Here  the  most  specific  state  of  the  represented  dimension  value  is  Open.  This  state  is  defined  based  on  the 
three  states  Direction,  Status,  and  Action  (defining  object  values  not  shown),  and  specializes  the 
ResultSet  state,  which  it  was  defined  as  a  case  of. 

A  dimension  is  also  Plaid's  version  of  a  trait.  Multiple  inheritance  is  achieved  by  allowing  multiple 
dimensions  to  be  composed  in  an  object  value  as  well  as  in  the  object  values  associated  with  the  tags  of  a 
dimension.  The  hierarchical  nature  of  Plaid’s  dimension  prevent  us  from  using  all  of  the  trait  mechanisms  for 
solving  the  problems  of  multiple  inheritance.  In  particular,  a  multiple  inheritance  system  must  deal  with  the 
case  when  one  class  inherits  from  two  classes  that  share  a  (transitive)  parent.  This  situation  is  challenging 
because  it  is  non-obvious  how  to  inherit  members  from  the  common  grandparent.  This  problem  is  commonly 
referred  to  as  the  diamond  problem  [19],  because  of  the  shape  of  the  inheritance  hierarchy  diagram.  The 
original  traits  proposal  [12]  flattens  6  composed  traits  and  forces  any  conflicts  between  method  names  to 
be  explicitly  resolved  (field  were  not  allowed  in  traits).  However,  as  Plaid’s  semantics  depend  on  members 
being  related  to  the  tag  they  are  defined  in,  we  cannot  use  flattening.  Instead,  Plaid  prevents  the  diamond 
problem  by  preventing  or-states  from  coexisting,  thereby  preventing  the  same  tag  and  member  definition 
from  appearing  more  than  once  (following  Malayeri’s  no-diamonds  rule  [19]).  Plaid’s  solution  follows  recent 
extensions  of  traits  including  [5,  22,  9].  Like  Plaid,  these  system  support  traits  with  fields  and  work  in  a 
variety  of  object  models  including  those  that,  like  Plaid,  add  hierarchy  and  do  not  enforce  the  flattening 
property.  As  with  the  original  trait  proposal,  all  name  conflicts  across  dimensions  must  be  explicitly  resolved 
in  Plaid  via  the  trait  operators  described  below. 

Member  values.  A  member  value  is  either  a  method,  with  a  set  of  arguments  and  a  body,  or  a  field,  val  /, 
bound  to  a  value,  v.  The  member  is  said  to  be  defined  in  the  state  represented  by  its  immediately  enclosing 

6The  flattening  property  from  [12]  states  that  members  of  an  are  treated  equally  regardless  of  what  trait  they  were  defined  in. 
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tag.  As  a  concrete  example,  an  object  in  the  ClosedFile  state  described  in  Listing  1  would  be  represented 
formally  as 

ClosedFilejmethod  close(){e}} 

<:  Filejval  filename  =  u} 

This  indicates  that  the  object  is  in  both  the  ClosedFile  and  the  File  states,  one  of  which  is  a  substate  of 
the  other,  and  each  of  which  defines  a  single  member. 

4.1.3  Uninitialized  Object  Syntax 

Plaid  has  corresponding  syntax  for  uninitialized  objects  organized  into  object  expressions,  dimension  expres¬ 
sions,  and  member  expressions.  When  compared  to  their  value  counterparts,  they  share  the  same  structure 
but  contain  expressions  which  are  not  yet  values.  In  this  section,  we  discuss  the  places  where  execution  can 
occur  in  these  forms  and  the  motivation  behind  them. 

Object  expressions.  Object  expressions,  oe,  are  made  up  of  the  composition  of  dimension  expressions, 
member  expressions,  as  well  as  raw  expressions.  The  purpose  of  unevaluated  expressions  in  dimension  and 
member  expressions  will  be  explained  below.  Raw  expressions  as  components  of  object  expressions  allow 
part  of  an  uninitialized  object  to  be  determined  at  the  time  of  initialization.  These  expressions  evaluate  to 
proto  values  which  are  then  incorporated  into  the  initializing  object.  This  provides  for  Plaid’s  implementation 
of  dynamic  trait  composition  by  allowing  portions  of  the  object  to  be  selected  at  runtime. 

Dimension  Expressions  Dimension  expression  can  contain  unexecuted  expressions  in  the  object  expression 
associated  with  the  most  specific  tag  as  well  as  in  tags  up  the  hierarchy  if  they  exist.  Dimension  expressions 
may  also  have  associated  trait  operations,  to,  which  need  to  be  evaluated.  Trait  operations  allow  standard 
manipulations  such  as  renaming,  n  — >  n' ,  and  removal,  \n.  Note  that  these  operate  on  the  whole  dimension, 
renaming  or  removing  all  members  of  the  specified  name  defined  directly  in  tags  in  the  hierarchy  (not 
including  nested  dimensions).  This  allows  the  changes  to  be  preserved  by  state  change  in  the  dimension  as 
we  will  see  below. 

Members  can  also  be  added  or  replaced7.  By  default,  they  are  (re)placed  in  the  most  specific  tag  of 
the  dimension  expression.  However,  In  cases  where  members  need  to  be  added  or  replaced  in  a  particular 
tag,  they  can  be  qualified  by  a  particular  tag,  specified  as  with  tags  in  case  statements  by  tagOf  another 
expression.  The  redefinition  of  Position  .  EndState  for  the  ReadStream  in  Listing  5  is  an  example 
of  using  qualified  trait  operations.  This  mechanism  is  important  in  Plaid  because  of  the  hierarchical  nature  of 
Plaid’s  object  model  and  when  and  how  member  definitions  are  removed  during  state  change. 

Member  expressions.  Only  fields  can  be  member  expressions,  me,  as  methods  do  not  have  any  initializa¬ 
tion  code.  On  the  other  hand,  fields  can  be  defined  with  initialization  expressions  that  require  evaluation 
as  a  part  of  object  creation  or  update.  In  order  to  allow  fields  to  refer  to  the  initialized  value  of  previous 
fields  in  the  same  state,  field  expressions  define  an  internal  bound  variable  in  addition  to  their  external  name 
(this  is  a  standard  approach  from  [21],  chapter  8).  Fields  are  also  generated  by  state  declarations.  Since 

7The  semantics  defined  here  do  not  allow  fields  and  states  in  trait  operations  to  refer  to  other  trait  operation  members.  The 
formalism  could  be  extended  to  support  this,  mirroring  the  case  for  declarations  in  states 
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Heap  H 
Eval  E 


obj  O 


[£  ov],  H  |  • 

1  I  let  x  =  E  in  e 


E(e)  v(v,E,e) 


E.m(e )  j  v.m(v,  E,  e)  E.f  [  E  -f- 
u  E  v  proto  E  «-  e  | 

u  «-  E  v  «-  proto  E  new  E 
new  proto  £  |  match(E){c}  | 
match(u){case(tagOf  E)  {e\,c} 
freeze  E 1  cw  r  £  |  0  y  oe  |  0 
val  n  t>  a;  =  E  |  tag{oe}  <:  E  | 
fag{E}  |  tag{E}  <:  dv  |  E{fo}  | 
dv{to ,  val  n  =  E,  to}  | 
dw{fo,  (tagOf  e).(val  n  =  E),to} 
du{fo,  (tagOf  E).mv ,  to} 


Figure  5:  Contexts 


the  definitions  of  related  states,  such  as  the  OpenFile  and  ClosedFile  from  Listing  1,  are  typically 
recursive,  the  initialization  of  state  members  occurs  in  a  recstate  binding. 

State  members  are  also  special  in  that  when  an  uninitialized  object  containing  state  members  is  initialized, 
new  tags  may  need  to  be  generated.  The  proto  expression  encapsulates  uninitialized  objects  as  discussed 
above.  Normally  they  contain  object  expressions,  but  when  appealing  in  a  recstate,  they  contain  state 
declarations,  sd  which  may  contain  the  freshtag  operations  that  generates  a  new  tag  when  executed,  resulting 
in  an  object  expression.  This  feature  means  that  new  tags  are  generated  for  states  defined  inside  states  each 
time  the  outer  state  is  instantiated.  Because  these  tags  can  then  be  used  to  pattern  match  on  objects,  this 
allows  Plaid  to  implement  ML-style  generative  functors8.  Functors  have  well  recognized  modularity  benefits 
that  we  do  not  discuss  here. 

4.2  Dynamic  Semantics 

We  now  introduce  the  dynamic  semantics  of  Plaid.  We  formalize  the  execution  using  a  small  step  operational 
semantics.  The  basic  evaluation  judgment  has  the  form  e@H  i-f  e'@EE  and  is  read  “expression  e  with  heap 
H  evaluates  to  expression  e1  in  heap  Hh\  We  define  a  similar  judgment  oe@H  i— >•  oe'@H '  for  the  evaluation 
of  object  expressions.  In  this  section,  we  will  define  the  form  of  the  heap  and  the  invariants  that  we  maintain 
on  it.  We  will  also  discuss  the  Plaid-specific  evaluation  rules,  in  particular  those  that  use  ancillary  judgments 
for  implementing  state  change.  As  state  change  is  at  the  core  of  Plaid’s  design  and  is  the  most  complicated 
we  go  into  depth  about  the  motivation  and  design  of  the  rules  that  implement  it.  Finally,  we  describe  object 
initialization  and  trait  operations  that  may  be  involved. 

4.2.1  Heap 

A  heap,  //.  is  a  mapping  from  locations,  t,  to  object  values.  We  place  additional  well-formedness  requirements 
on  all  object  values  stored  in  the  heap.  These  restrictions  prevent  ambiguities  from  multiple  inheritance. 

Generative  functors,  in  contrast  to  applicative  functors,  generate  new  abstract  types  for  each  application  of  the  functor.  This 
impacts  pattern  matching  when  using  these  generated  types  in  a  similar  way  as  pattern  matching  on  freshly  generated  tags  in  Plaid. 
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Figure  6:  Expression  Evaluation 


Tag  uniqueness.  We  require  that  all  well-formed  object  values  have  no  duplicate  tags.  As  alluded  to  above, 
this  property  ensures  that  an  object  is  not  in  two  cases  of  a  single  or-state  at  the  same  time.  This  is  because 
the  tags  representing  two  mutually  exclusive  or-states  must  come  from  the  same  dimension  and  thus  must 
have  at  the  least  the  root  tag  of  the  dimension  in  common.  It  also  prevents  the  diamond  problem  of  multiple 
inheritance  by  ensuring  that  a  particular  member  definition  does  not  appear  multiple  times  in  a  single  object. 
This  invariant  is  encoded  in  the  helper  judgment  uniqueTags  also  defined  in  Figure  10. 

Member  uniqueness.  Even  though  a  given  definition  for  a  member  cannot  appear  more  than  once,  it  is 
still  possible  that  multiple  tags  define  members  with  the  same  name.  To  prevent  ambiguities  in  this  case 
we  require  that  all  members  of  an  object  arc  provided  by  exactly  one  dimension.  Because  the  hierarchy  of 
dimensions  gives  us  a  natural  way  to  choose  the  visible  definition  (the  one  from  the  most  specific  tag  in  the 
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dimension)  we  allow  a  single  name  to  be  defined  directly  in  multiple  tags  from  a  single  dimension.  Formally, 
two  tags  are  in  the  same  dimension  is  one  is  a  transitive  case  of  the  other.  This  relaxation  of  classical  traits 
allows,  for  instance,  a  common  super  state  to  define  a  default  behavior  for  a  method  which  can  be  overridden 
by  (some  of)  its  substates.  The  judgment  uniqueMembers  defined  in  Figure  10  captures  this  requirement. 
It  uses  the  judgments  mv  ::  tag.x@ov,  which  states  that  member  value  rnv  from  tag  tag  defines  name  x  in 
object  value  ov,  and  tag  «  tag'@ov  which  asserts  the  property  that  tag  tag  is  a  transitive  subtag  of  tag 1  in 
object  value  ov.  Based  on  these  helper  judgments,  an  object  value  has  unique  members  if  whenever  we  find 
the  same  member  defined  in  two  tags,  then  one  of  these  tags  is  a  transitive  subtag  of  the  other.  We  prove  that 
evaluation  preserves  member  and  tag  uniqueness  in  appendix  A. 

Member  lookup.  As  an  object  can  contain  multiple  members  with  the  same  name,  we  need  an  unambiguous 
way  to  choose  which  one  is  visible.  The  lookup  function  also  in  Figure  10  defines  this  logic.  When  multiple 
definitions  are  found,  we  know  by  uniqueMembers  that  they  all  come  from  the  same  dimension.  Since  the 
tags  of  a  dimension  form  a  total  order,  we  know  that  one  of  tags  defining  the  member  will  be  a  transitive 
subtag  of  all  other  tags  defining  the  member.  The  definition  from  this  most  specific  tag  is  the  one  returned  by 
lookup. 

4.2.2  Expressions 

The  evaluation  rules  for  expressions  in  Plaid  arc  given  in  Figure  6.  We  only  list  only  computation  rules  here, 
defining  congruence  rules  using  evaluation  contexts  shown  in  Figure  5.  In  these,  each  expression  with  a 
subexpression  that  requires  evaluation  defines  a  hole,  [  ],  into  which  any  expression  can  be  placed.  Evaluation 
proceeds  by  using  the  computation  rule  that  evaluates  the  expression  in  the  hole. 

Standard  rules.  The  computation  rules  for  the  evaluation  of  the  expressions  from  general  object  systems 
and  the  lambda  calculus  are  almost  all  completely  standard  in  our  system.  These  include  the  rules  E-Let,  E- 
App,  E-Call,  and  E-Field  for  let  expressions,  application,  method  calls  and  field  dereferences  respectively. 
One  note  is  that  member  selection  during  calls  and  dereferences  use  the  lookup  judgment  described  above. 
We  also  use  standard  record  evaluation  rules  when  selecting  a  label  from  a  recstate  (E-RecstateSelect). 

Match.  Plaid  uses  a  first-match  semantics,  so  that  we  find  the  first  case  clause  whose  tag  matches  the 
target  object.  We  find  the  tag  to  match  against  by  grabbing  the  most  specific  tag  (tagOf)  from  a  dimension 
expression  wrapped  in  a  proto  value.  Note  that  in  this  case  the  dimension  expression  is  not  evaluated  since 
we  are  only  interested  in  the  tag.  If  the  tag  is  found  in  the  target  object,  the  code  for  this  case  is  evaluated 
(E-CaseMatch);  otherwise,  execution  proceeds  to  the  next  case  (E-CaseNotMatch).  Default  cases 
are  always  executed  and  terminate  the  match  if  reached  (E-CaseDefault).  Evaluation  gets  stuck  if  no 
matching  case  is  found. 

Freezing.  To  freeze  a  location  in  the  heap  (E-Freeze),  we  simply  pull  the  object  value  from  the  heap  and 
wrap  it  in  a  proto  expression. 

Manipulating  objects  in  the  heap.  The  state  change  operators  and  new  cause  objects  in  the  heap  to  be 
changed  or  allocated.  Because  we  only  allow  object  values  to  appeal-  in  the  heap,  we  must  first  initialize  the 
object  that  will  be  used  to  alter  the  heap  by  reducing  it  to  an  object  value.  Evaluation  is  mostly  handled  by 
the  evaluation  contexts:  first  the  expression  representing  the  object  is  reduced  to  a  proto  value  and  then  the 
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Of  i —  Of  =t>  Of 


OVt  i —  OV  =£•  Of  Of  Ofu  =>  OVo 

- SU-List  - SU-Mv 

oft  <—  of  t  ovu  =>-  of o  oft  <—  mvu  =>  oft  x  mvu 


tags(oft)  PI  tags(dfu)  =  0  uniqueTags(dfu) 

- SU-AddH 

ovt  dvu  =>  oft  x  dvu 


tags(df)  n  outerTags(dfu)  /  0 

df  <—  dvu  dvr 

tags(of)  n  tags(dfr)  =  0 

- SU-MatchDim 

ov  x  dv  i —  dvu  =>  of  i  dfr 


outerTags(dfu)  n  tags(of)  /  0  of  f-  dfu  =>  ofr 

[tags(dfn)  n  tags(df)  =  0]  tag  0  tags(dfu) 

- SU-MatchInner 

ta<?{of}[<:  df]  4—  dfn  =>  tag{ofr}[<:  dv] 

outerTags(dfu)  H  innerTags(df )  /  0  dv  <—  dvu  =>  dvr 
tags(iag{of  })  D  tags(dfu)  =  0 

- - — - - - — - - SU-MatchSuperInner 

tag{ov\  <:  dv  <—  dvu  =$■  tag{ov\  <:  dvr 

tag  outerTags((ifu)  outerTags(dfu)  H  outerTags(df )  /  0 

dv  <—  dvu  dvr 

- - — - - SU-MatchSuper 

tag{ov}  <:  dv  <—  dvu  =>•  dvr 

dvu  =  [dvsub]  <:  tag{ov'}  <:  [dvsup\ 

[tags(dvsub)  H  tags(tag{ov}[<:  dv])  =  0]  uniqueTags((ifsub) 

- SU-Match 

ta<7{of}[<:  dv]  <—  dvu  =>  [dvsub]  <:  tag{ov}[<:  dv] 


Figure  7:  State  Update 


object  expression  wrapped  in  the  proto  is  evaluated  down  to  an  object  value.  An  important  design  decision 
in  Plaid  was  to  run  the  initializers  for  all  members  of  an  object  expression.  This  happens  despite  the  fact 
that  not  all  members  may  end  up  in  the  object  (see  the  explanation  of  state  update  below).  In  particular,  any 
effectful  initializers  will  always  be  run  and  update  the  wider  context.  We  experimented  with  other  possible 
semantics  but  decided  that  a  clear  and  unambiguous  rule  for  when  initializers  were  run  (always)  was  better 
than  a  flexible  but  complicated  one.  Furthermore,  we  consider  it  good  Plaid  style  to  avoid  the  use  of  effectful 
initializers  and  instead  use  other  design  techniques,  such  as  factory  methods,  when  effectful  operations  are 
required  as  a  part  of  object  initialization. 

Once  the  initialization  code  in  the  proto  has  been  run,  the  resulting  object  value  can  be  used  to  update 
the  heap.  In  the  case  of  new  and  state  replacement  («-)  expressions  it  is  clear  what  the  object  value  that  is 
inserted  into  the  heap  will  be.  new  allocates  a  new  location  on  the  heap  and  maps  it  to  the  resulting  object 
value.  State  replacement  replaces  the  mapping  of  the  target  location  on  the  heap  with  the  updating  object 
value.  Since  we  know  the  precise  form  of  the  object  value  that  is  being  inserted  into  the  heap,  in  order  to 
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1  val  rs  =  Open  { 

2  Inserted  <:  Inserting  <:  Action, 

3  Scrollable  <:  Direction, 

4  Updatable  <:  Status  } 

5  <:  ResultSet 

Listing  7:  Open,  Inserted,  Scrollable,  Updatable  ResultSet 


maintain  the  heap  invariants  on  object  values,  we  can  simply  check  that  uniqueTags  and  uniqueMembers 
both  hold  on  the  new  object  value  as  done  in  the  rules  E-Replace  and  E-New.  On  the  other  hand,  the 
semantics  of  updating  an  object  on  the  heap  using  state  update  are  much  more  complicated,  and  so  we  devote 
the  next  section  to  a  discussion  of  its  design  and  proof  that  they  maintain  the  necessary  invariants. 

4.2.3  State  Update 

At  the  core  of  the  rule  E-SU  which  updates  the  heap  with  the  result  of  a  state  update  is  the  state  update 
judgment,  ov  <—  ov  =>•  ov,  which  is  described  in  Figure  7.  The  judgment  takes  two  object  values  and 
determines  the  resulting  object  value  when  the  target  object  on  the  left  side  of  the  arrow  is  changed  to  the  state 
given  by  the  update  object  from  the  right  side.  The  semantics  of  this  judgement  are  the  most  complicated  and 
important  part  of  Plaid's  dynamic  semantics.  Thus,  before  describing  the  semantics  given  by  the  rules,  we 
step  back  and  give  a  high-level  overview  of  the  desired  behavior.  We  then  define  some  general  properties  and 
assumptions  of  the  judgment  before  describing  the  rules  themselves. 

Design  considerations.  Our  goal  is  that  the  design  of  the  state  change  judgment  should  match  the  semantics 
of  stateful  abstractions  as  modeled  by  state  charts  and  similar  tools.  Thus,  a  state  update  should  transition  a 
target  object  from  its  current  set  of  abstract  states  to  a  possibly  new  set  of  abstract  states  as  specified  by  the 
update  object.  To  do  this,  we  need  to  formalize  this  intuition  in  terms  of  object  values. 

Update  dimensions.  Our  first  task  is  to  determine  which  abstract  state  the  update  object  is  changing. 
That  is,  which  dimensions  of  the  target  object  need  to  be  updated?  Consider  the  object  value  (without 
members)  of  an  Open  ResultSet  in  the  Inserted,  Scrollable,  Updatable  state,  stored  in  val  rs 
as  depicted  in  Listing  7.  What  should  happen  if  we  update  rs  to  the  Readonly  state? 

rs  4—  Readonly  <:  Status 

While  there  are  clearly  matches  between  tags  in  the  target  and  update  objects,  since  the  tags  are  nested  inside 
the  Open  tag  of  the  target  object,  it  is  not  clear  that  they  should  be  updated.  However,  if  we  think  of  the  state 
update  as  an  transition  to  a  new  abstract  state,  then  we  can  see  that  the  nesting  in  the  target  object  should  not 
matter.  This  state  update  specifies  that  the  Status  dimension  should  transition  to  the  Readonly  substate, 
and  thus  out  of  the  Updatable  state. 

The  converse  question  is  does  nesting  matter  in  the  other  direction?  In  other  words,  can  a  nested  state 
trigger  a  change  in  an  abstract  state?  Concretely,  would  this  state  update 

rs  4—  FoojReadOnly  <:  Status} 

result  in  an  object  in  the  Readonly  state?  Based  on  the  semantics  of  state  charts,  the  answer  would  be 
“no”.  Our  definitions  of  object  dimension  indicates  that  the  Status  dimension  of  the  Foo  state  is  part  of  the 
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definition  of  Foo.  Thus,  it  is  brought  along  with  the  transition  to  the  Foo  state.  The  Status  state  is  also  a 
defining  and-state  of  the  Open  state.  Thus  the  resulting  object  cannot  be  consistent  because  two  separate 
dimensions  arc  claiming  the  Status  state  meaning  there  would  need  to  be  duplicate  tags. 

Therefore,  we  define  the  dimensions  along  which  a  state  update  occurs  to  be  only  those  found  at  the  top 
level  of  the  object  value  that  describes  the  update  object.  All  other  dimensions  that  arc  a  paid  of  the  update 
object  arc  considered  definitions  of  these  dimensions  and  do  not  induce  transitions  but  arc  only  added  to  the 
object  with  their  enclosing  state. 

Dimension  updates.  Once  we  know  which  dimensions  will  be  updated,  we  need  to  know  what  in  those 
dimensions  is  changed.  We  first  note  that  we  can  treat  the  transition  in  each  dimension  independently  as 
dimensions  are  orthogonal  by  definition.  Second,  recall  the  file  example  from  Listing  1.  In  this  example, 
we  stated  that  the  filename  member  was  shared  between  the  OpenFile  and  ClosedFile  states.  Thus, 
when  we  transition  from  an  ClosedFile  to  an  OpenFile  the  members  of  the  File  state  should  remain 
constant.  This  is  the  semantics  behind  the  restricted  update  semantics  of  state  change  described  in  [1],  We 
use  and  extend  these  semantics  in  a  natural  way  to  account  for  our  hierarchical  object  model. 

Properties  of  object  and  state  update.  With  the  intuition  we  have  for  the  design,  we  can  define  some 
terminology  that  is  used  in  the  judgment  itself. 

Inner  and  outer  tags.  In  the  informal  description  of  state  change,  we  differentiated  between  dimen¬ 
sions  and  tags  defined  at  the  top  level  of  the  update  object  and  those  that  appear  within  a  top-level  dimension. 
Figure  10  defines  two  judgments,  outerTags  and  innerTags,  which  capture  this  distinction.  The 
outerTags  of  an  object  value,  ov,  are  all  the  tags  which  appear  as  the  most  specific  tag  and  any  of  its  super 
tags  from  dimensions  appealing  directly  in  ov.  For  example,  using  rs,  the  Re  suit  Set  object  from  Listing  7, 
outerTags(rs)  =  {Open,  ResultSet}.  Conversely,  the  innerTags  of  an  object  value  are  all  of  the 
tags  defined  in  dimensions  that  are  recursively  included  in  the  definition  of  each  of  the  outer  tags.  For  example, 

innerTags(rs)  =  {Inserted,  Inserting,  Action, 

Scrollable, Direction, Updatable, Status} 


Unique  dimension  property.  Given  a  dimension  within  which  to  transition  the  target  object,  we  need 
to  find  the  location  of  the  matching  dimension  within  the  target  object  value.  To  do  this,  we  look  for  the  paid 
of  the  object  that  has  tags  which  overlap  the  outer  tags  of  the  update  dimension.  We  ignore  all  super-tags  of 
the  matching  tag  in  the  update  dimension  under  the  assumption  that  these  supertags  will  match  the  tags  in  the 
target.  This  assumption  is  based  on  the  the  Unique  Dimension  Property  which  states  that  a  single  unique 
tag  can  only  ever  appeal-  in  a  single  dimension.  That  is  a  tag  is  either  has  no  super  tags  or  always  appears 
with  the  same  supertag.  While  this  property  is  not  guaranteed  by  the  syntax  and  semantics  of  the  internal 
language,  it  is  enforced  by  the  elaboration  from  Plaid’s  source  syntax  so  we  assume  it  in  our  rules. 

Maintaining  the  uniqueTags  property.  Rule  E-Su  in  Figure  6  does  not  check  whether  the  object 
returned  from  the  state  update  judgement  has  unique  tags.  Therefore  the  state  update  judegment  must  maintain 
this  property.  Formally:  If  uniqueTags (ov\)  A  ov\  *—  ov 2  =>  ov 3,  then  uniqueTags(cws).  A  proof  of  this 
property  can  be  found  in  appendix  A. 
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oe@H ;  T  H>  oe@tf;  T 
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Figure  8:  Object  Evaluation 


Inference  rules.  With  this  understanding,  we  can  describe  the  rules  that  produce  the  object  value  after  a 
state  update  operation.  The  rules  start  by  breaking  apart  the  update  object  ov  into  the  individual  member 
values  and  dimension  values  and  processing  the  state  changes  for  each  dimension  or  value  individually  (SU- 
List).  This  is  allowed  since  each  dimension  can  be  treated  independently.  We  can  assume  that  uniqueTags 
holds  for  each  dimension  individually  since  it  holds  for  the  object  as  a  whole.  For  member  values  (SU-Mv) 
and  dimension  values  for  which  there  is  no  overlap  between  the  tags  of  the  target  object  and  update  dimension 
(SU-AddH),  we  just  compose  the  update  object  with  the  target  object.  The  rest  of  the  rules  assume  that  there 
is  a  match  between  the  outer  tags  of  the  update  object  and  the  tags  of  the  target  object.  If  that  is  not  the  case, 
then  the  evaluation  gets  stuck. 

SU-MatchDim  covers  the  case  where  we  have  found  a  particular  dimension  of  the  target  object  that 
contains  the  tags  that  are  changing.  By  the  unique  dimension  property  explained  above,  we  know  that  the 
outer  Tags  (dr;,,)  will  not  appeal-  in  ov,  so  it  suffices  to  calculate  the  state  update  on  just  the  matched 
dimension.  To  ensure  that  we  maintain  the  unique  tags  property,  we  can  assume  that  both  the  result  of  the 
state  update  and  the  unmatched  portion  of  the  object  have  unique  tags,  and  so  it  suffices  to  check  that  the  tags 
of  these  two  portions  of  the  object  do  not  intersect. 

SU-MatchInner  handles  the  case  where  there  is  overlap  between  the  innerTags  of  the  current  tag 
and  the  outerTags  of  the  update  dimension.  We  recursively  find  the  state  update  on  just  this  matching 
portion  and  then  check  that  the  tags  from  the  resulting  object  value  do  not  intersect  with  the  tags  of  the  super 
tag,  if  it  exists,  to  maintain  the  uniqueTags  invariant. 

In  SU-MatchSuperInner,  we  find  that  the  matching  dimension  is  defined  somewhere  inside  of  a 
super  tag.  Thus,  we  run  state  update  on  just  the  supertags.  We  then  verify  that  the  tags  of  the  result  are 
distinct  from  the  tags  of  the  subtag  and  its  innerTags  to  maintain  the  uniqueTags  invariant. 
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SU-MatchSuper  represents  the  case  where  we  have  found  the  right  dimension,  but  have  not  reached 
the  level  of  the  dimension  where  the  tags  overlap.  The  current  tag  of  this  dimension  is  not  in  the  outer  tags 
of  the  update  dimension,  but  there  is  overlap  somewhere  in  its  super  tags  and  so  we  find  the  updated  state 
from  that  portion  of  the  dimension.  In  this  case,  we  know  that  the  current  tag  will  be  removed  with  any  of  its 
nested  tags,  which  means  that  we  do  not  need  to  check  if  these  tags  would  conflict  with  tags  that  enter  the 
object  with  the  update  dimension  to  preserve  uniqueTags. 

The  base  case  SU-Match  handles  the  actual  alteration  of  the  target  dimension.  The  current  tag  matches 
a  specific  tag  in  the  outer  tags  of  the  update  dimension,  which  indicates  that  the  state  update  only  affects 
states  below  this  point  in  the  dimension.  In  particular  the  tags  below  this  one  in  the  dimension  in  the  target 
object  are  discarded,  as  already  occurred  through  the  SU-MatchSuper  rule.  In  their  place  arc  put  all  the 
subtags  of  the  matched  tag  from  the  incoming  dimension.  To  make  sure  that  we  do  not  have  duplicate  tags 
anywhere,  we  only  need  to  check  that  the  tags  added  from  the  update  dimension  do  not  intersect  with  the  tags 
that  arc  in  its  new  supertags. 

Example.  To  give  a  specific  example,  consider  evaluating  the  following  state  update  on  the  object  defined 
in  Listing  7 : 


rs  4—  Readonly  <:  Status 

The  state  updates  proceeds  first  by  finding  that  there  is  tag  overlap  between  the  incoming  and  target 
objects  and  a  match  for  the  Status  tag  of  the  incoming  state  nested  inside  the  Open  state  with  the  SU- 
MatchInner.  Next  it  finds  the  correct  dimension  Updateable  <:  Status  using  the  SU-MatchDim  rule. 
It  discards  the  Updateable  tag  and  recurses  up  the  dimension  in  the  SU-MatchSuper  rule  and  finally 
adds  the  Readonly  tag  in  its  place  with  the  SU-Match  rule. 

Reduction  rule  The  E-SU  reduction  rule  uses  the  state  update  judgement  to  determine  what  object  value 
to  update  the  target  object  to.  The  state  update  judgement  incrementally  checked  that  uniqueTags  was 
maintained.  It  does  not  guarantee  that  uniqueMembers  is  satisfied  and  so  the  rule  checks  that  the  resulting 
object  value  has  unique  member  declarations. 

4.2.4  Object  Evaluation 

The  final  class  of  reductions  that  we  must  model  is  that  of  state  expressions,  including  the  initialization  of 
object  expressions  within  a  proto.  These  rules  are  defined  in  Figure  8.  Congruence  rules  are  again  taken  care 
of  by  evaluation  contexts  from  Figure  5. 

•  E-RecField:  When  field  members  have  been  evaluated  down  to  values,  we  propagate  them  forward 
into  the  rest  of  the  declarations  that  need  to  be  initialized  by  substituting  the  value  in  for  the  bound 
variable  on  the  right  of  the  [>.  This  allows  subsequent  fields  to  use  the  values  of  previously  declared 
fields  during  their  initialization.  After  this  propagation,  we  do  not  need  to  keep  track  of  the  bound 
variable  any  longer  and  so  do  not  record  it  in  the  member  value.  Note  that  these  semantics  force  us  to  be 
strict  about  the  order  in  which  portions  of  the  object  arc  initialized.  In  particular'  member  declarations 
are  initialized  from  left  to  right  as  specified  by  the  evaluation  contexts. 

•  E-RecstateI:  If  there  are  freshtag  directives  in  the  state  declarations  of  a  recstate,  new  tags  are 
generates  by  picking  a  fresh  tag  not  previously  mentioned. 
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•  E-RECSTATE2:  After  assigning  new  tags  to  all  of  the  state  declarations  inside  a  recstate,  we  need  to 
remove  the  recstate  construct  and  convert  it  into  a  list  of  val  declarations.  This  is  done  in  a  manner 
similar  to  the  fix  construct  in  the  lambda  calculus.  Since  our  recstate  is  modeled  as  a  record,  we 
replace  all  references  to  the  inner  bound  variable  of  each  of  the  nested  state  vals  with  selections  of  the 
external  name  from  the  recstate.  We  do  this  both  inside  the  object  expressions  of  each  proto  as  well  as 
in  subsequent  declarations.  Note  again  that  after  propagation  we  can  remove  the  bound  variable  from 
the  val  declaration. 

•  E-De  and  E-Oe:  These  rules  state  that  it  is  possible  to  unwrap  a  proto  that  is  nested  inside  another 
proto.  This  can  occur  when  a  proto  is  part  of  an  object  expression  inside  another  proto  (E-Oe),  or 
when  a  proto  is  in  a  dimension  expression,  which  only  appear  in  proto  expressions  (E-De).  In  either 
case,  if  trait  operations  are  associated  with  this  proto,  then  they  are  retained.  Execution  will  continue 
by  evaluating  the  wrapped  object  expression  if  needed. 

•  E-TraitOpS:  This  rule  applies  only  once  the  all  of  the  trait  operations  have  been  fully  reduced  and 
proceeds  using  the  trait  operations  judgment  defined  below  to  produce  a  new  dimension  value. 

4.2.5  Trait  Operations 

As  with  state  change,  we  define  a  separate  judgement  for  trait  operations  that  applies  once  all  trait  operations 
have  been  fully  initialized,  meaning  that  they  can  all  be  applied  atomically  without  reduction.  The  rules  for 
initialization  of  trait  operations  arc  all  congruence  rules  handled  by  evaluation  contexts  (see  Figure  5).  Thus, 
the  judgement,  ov{sp}  =>  ov,  does  not  require  a  heap.  In  general,  trait  operations  follows  previous  work  on 
traits.  However,  Plaid’s  object  model,  unlike  traditional  traits  models,  is  hierarchical.  Hence,  trait  operations 
other  than  the  local  member  addition  must  take  this  hierarchy  into  account. 

Local  member  updates  are  agnostic  to  whether  the  added  member  is  already  a  member  of  the  tag  and 
simply  add  the  new  member,  replacing  the  existing  member  if  one  exists  (T-Member).  Updates  of  members 
in  specific  tags  act  the  same,  but  first  must  recurse  through  the  object  value  looking  for  the  specified  tag 
before  performing  the  member  update.  The  computation  will  get  stuck  if  the  tag  is  not  found.  Because  each 
of  these  trait  operations,  as  well  as  member  renaming  described  below,  may  potentially  add  new  members, 
there  is  the  danger  that  the  object  value  might  no  longer  satisfy  the  uniqueMembers  invariant.  However, 
since  the  specialization  must  be  occurring  as  part  of  object  instantiation,  it  will  be  checked  at  the  point  that 
the  object  is  created,  so  we  do  not  make  the  check  here. 

Member  removal  and  renaming  operate  on  the  whole  object,  removing  or  renaming  instances  of  members 
with  the  given  name  throughout.  This  is  in  contrast  to  lookup,  which  stops  at  the  first  declaration  of  the 
member.  These  semantics  are  required  in  order  to  allow  trait  composition,  which  includes  the  ability  to 
remove  members  from  a  trait  and  instead  provide  them  in  another  trait.  This  would  result  in  a  conflict  if  some 
members  were  left  in  the  old  dimension. 

5  Elaboration 

The  core  language  defined  in  the  previous  section  shares  much  in  common  with  the  full  Plaid  programming 
language,  but  there  arc  still  differences.  The  source  syntax  is  defined  in  figure  11.  The  semantics  of  the  full 
Plaid  language  are  defined  as  an  elaboration  into  the  core  language  defined  in  appendix  B. 

For  most  expressions,  the  elaboration  proceeds  structurally,  without  changing  the  construct  itself.  For 
field  bindings,  we  add  the  internal  variable  referred  to  above,  and  replace  references  to  the  field  in  later  field 
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ov{to}  =>•  ov 


dv{to }  =>  dv'  dv' {to}  =>  dv"  ov  =  ov'\  x  mv']  [nam e(mv')  =  x  =  name(mv)] 

- T-GENERAL  - ; - ; - — - - - - ; - ; - — - r^T-MEMBER 


dv{to1  to}  =»  dv” 

ow{\n}  =>  ov1  [dc{\n}  =4>  dv') 

( tag{ov}[< :  c?w]){\n}  =>  tag{ov'}\< :  dv'} 

name(??Tu)  =  n  cw{\n}  =>  ov' 


(tag{ov}[<:  dv]){mv}  =£■  tag{ov'  T  mv}[<:  dv] 
dv{\n}  =>■  dv1  oi>{\n}  =>  ov' 

T-RemoveDv  - - - — — - - - - - T-RemoveOvI 

(dv  x  ov){\n}  =>  dv  x  ov 

name  (mu)  ^  n  ou{\n}  =>  ov’ 


T-RemoveOv2 


(mv  t  ou){\n}  =>  ov'  (mv  x  ou){\?r}  =>  mv  x  ov' 

ov{n  — >  n'}  =>  ov'  [dv{n  —>  n'}  =>  dv'}  r 


T-RemoveOv3 


(tag{ov}[<:  dz»]){\n}  =>  tag{ov'}[< :  dv'] 
dv{n  — ►  n'}  =>  dv'  ov{n  —>  n'}  =>■  ov 


-T-RenameDv 


T-RenameOvI 


(dv  x  ov){n  — >  n'}  =>  dv'  x  ov’ 
naiae(mv)  =  n  renam e(n',mv)  =  mv'  ov{n  — >  n'}  =>  ov' 


(mv  T  ov){n  — >  n'}  =>■  mv'  x  ov' 

nam e(mv)  ^  n  ov{n  — >  n'}  =>  ov' 

(mv  x  ov){n  — >  n'}  =>•  mv  x  ov' 

de  =  tag{oe}{<\  de'}  ov{tag.mv}  =>•  ov' 
(<w){(tagOf  proto  de).mv}  =>  ov' 

tag  tags  (dv)  ov{tag.mv}  =>  ov' 

(dv  T  ov){tag.mv}  =>  dv  x  ov' 

tag  £  tags  (dv)  dv{tag.mv}  =>■  dv' 


T-Rename0v2 


T-Rename0v3 


T-StateMember 


T-StateMemberOv  1 


(dv[  T  ov]){t.ag.mv}  =>  dv  [  T  ov] 

tag  ^  tag '  ov{tag' .mv}  =>  ov'  [dv{tag .mv}  =>  dv'] 

(tag{ov}[<:  dv]){t.ag' .mv}  =>  tag{ov'}[<:  dv'] 

(tag{ov}[<:  dv]){mv}  =>  dv' 


T-StateMember0v2 


T-StateMemberDvI 


(tag{ov}[<:  dv]){tag.mv}  =>  dv' 


T-StateMemberDv2 


Figure  9:  Trait  Operations 


initializers  with  the  fresh  variable.  Sequences  of  state  declarations  are  transformed  into  recstate  blocks.  Each 
state  declaration  is  transformed  into  a  val  declaration  which  binds  to  a  proto  representing  the  uninitialized 
state,  with  a  f  reshtag  expression  for  generating  the  state’s  tag  when  the  declaration  is  executed. 

Our  formal  semantics  defines  all  of  the  Plaid  language  except  for  module  linking  and  cross  language 
binding.  Module  linking  currently  follows  the  Java  standard,  including  packages,  imports,  and  a  classpath 
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uniqueTags(ov)  uniqueMembers(ov)  lookup(a;,  ov)  =  mv  dv  £  ov  mv::tag.x@ov 
tag  «:  tag@ov  validTagMembers(ot>)  renam e(n,mv)  =  mv  nam e(mv)  =  n 

tags(ov)  outerTags(ov)  innerTags(ov) 


tag  tags(ov)  [  U  tags(dv)]  [tags(ov)  fl  tags(dv)  =  I 

uniqueTags(ov)  [uniqueTags(dv)] 


uniqueTags(ia(/{ov}[<:  dv]) 
tags(dv)  H  tags(ov)  =  0  uniqueTags(dv)  uniqueTags(ov) 


UniqueTagsDv 


LiqueTags(dv  T  ov) 


UniqueTagsOvI 


[uniqueTags(ov)] 
uniqueTags(mv[  t  ov]) 


UniqueTagsOv2 


mv i  ::  tagi.x@ov  ...  mvn  ::  tagn.x@ov 
tag-i  <<:  tagi@ov  ...  tagi  «:  tag„@ov 
lookup(®,  ov)  =  mvi 


Lookup 


validTagMembers(ov) 

3n(3tag  mv  ::  tag.n@ov  A  3 tag'  mv'  ::  tag'  ,n@ov)  =>  ( tag  <<:  tag'@ov  V  tag1  <<:  tag@ov) 


uniqueMembers(ov) 


UniqueMembers 


-LeafI 


dv  £  ov' 


dv  €  dv  dv  £  mv  r  ov1 

tag  ^  tag1  tag{ov}[<-.  dv]  £  ov' 
tag{ov}[<:  dv]  £  tag'{ov'}  <:  dv'[y  ov"] 

tag{ov'}  <:  dv  £  ov 
tag'  £  outerTags(tag{oi/}  <:  dv) 


LEAF2 


Leaf4 


tag  ^  tag  tag{ov}[<\  dv]  £  dv' 
tag{ov}[<:  dv]  £  tag' {ov'}  <:  dv']rov"] 

tag{[ov i  r]mv[yovi]}  <:  dv  £  ov 


LEAF3 


mv  ::  tag@ov 


MbrInTag 


tag  «:  tag'@ov 


CaseOf 


name(mv)  names 

[validTagMembers(names  U  name(mv),  ov')] 
validTagMembers(names,  mv[  r  ov']) 


VTM1 


validTagMembers(0,  ov)  [validTagMembers(0,  dv)]  [validTagMembers(names,  ov')] 
validTagMembers(names,  ( tag{ov}[< :  dv])[  T  ov']) 


VTM2 


- Name]  -  Name2  - - - - - RenameI 

n  =  name(val  n  =  v)  m  =  name(method  m(x){e})  rename(a,  val  n  =  v)  =  val  a  =  v 


rename(n,  method  m(x){e})  =  method  n(a;){e} 


-Rename2 


tags(ov)  =  innerTags(ov)  U  outerTags(ov) 
-OuterDv 


-Tags 


outerTags(iag{ov}[<:  dv])  =  {tag}  [U  outerTags(dv)] 

outerTags(dv[  r  ov])  =  outerTags(dv)  [U  outerTags(ov)] 

- - - - - - — - - — -  OuterOv2 

outerTags(mv[  r  ov J)  =  0  [U  outerTags(ov)] 


-OuterOvI 


innerTags(2a<?{ov}[<:  dv])  =  tags(ov)  [U  innerTags(dv)] 


-InnerDv 


innerTags(dv[  T  ov])  =  innerTags(dv)  [U  innerTags(ov)] 

- - - - - - — - - — -  InnerOv2 

innerTags(mt)[  r  ovj)  =  0  [U  mnerTags(ov)] 


InnerOvI 


Figure  10:  Helper  Judgements 
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Declarations 

D 

::=  SD  |  method  m{x){SE }  | 

val  /  =  SE 

State  Decl. 

SD 

::=  val  s  =  S 

state  s  =  S 

state  s  case  of  s{TO}  =  S 

States 

S 

::=  freeze(S'.E)  1  {D}  1  s{T}  1 

S  with  S  | 

SE.s  |  s 

Trait  Ops 

TO 

::=  \n  1  n  — t 

n!  1 

val  /  =  SE  val  s  =  S 

val  s.f  = 

SE  val  s.t  =  S 

method  m(x){SE}  \ 

method  s.m(x){SE } 

Expression 

SE 

::=  x  |  let  x  = 

--  SE  in  SE  |  SE.f  \ 

SE(SE ) 

SE.m(SE )  | 

SE  «—  S 

SE  «-  S  new  S 

match  (SE){C} 

Case 

C 

:=  case  SE. 

s{SE} 

case  s  {577}  default  {£'£’} 

Compil.  Unit 

cu 

::=  D 

Figure  11:  Source  Syntax 


for  loading  elements.  Plaid  primitives  are  defined  using  Java  classes  and  methods,  which  can  be  directly 
accessed  in  Plaid  via  their  fully-qualified  Java  names.  Details  of  both  of  these  aspects  of  Plaid  are  discussed 
in  more  detail  in  the  Plaid  language  definition  [17]. 

6  Discussion  and  Future  Work 

The  primary  contribution  of  the  Plaid  language  is  providing  a  way  for  programmers  to  express  state  machine 
abstractions  directly  in  the  source  code  of  their  programs.  Plaid  supports  the  major  state  modeling  features  of 
Statecharts,  including  state  hierarchy,  or-states,  and  and-states.  The  explicit  representation  of  states  makes 
the  design  more  salient  in  the  code,  enhancing  programmer  understanding.  For  example,  the  separation 
of  members  into  different  abstract  states  helps  programmers  quickly  learn  what  operations  arc  available  in 
each  state.  In  the  future,  visualization  tools  that  leverage  explicit  state  constructs  to  automatically  generate 
statecharts  from  Plaid  code  could  provide  even  greater  benefits. 

Plaid  has  the  potential  to  make  code  more  reliable.  Not  only  do  explicit  states  help  programmers 
understand  libraries  better,  avoiding  errors  in  the  first  place;  the  runtime  will  also  verify  that  the  libraries  arc 
used  correctly  according  to  their  state  abstractions.  Even  a  “method  not  available  in  this  state”  error  is  better 
than  a  silent  corruption,  but  in  future  work,  we  believe  we  can  leverage  explicit  states  to  do  much  better.  For 
example,  a  state -related  error  message  could  be  paired  with  a  suggestion  about  what  methods  could  be  called 
in  order  to  move  the  object  into  a  correct  state. 

Plaid’s  trait-like  state  composition  model  provides  a  way  of  reusing  not  just  fields  and  methods,  but  state 
abstractions.  This  additional  layer  of  reuse  has  the  potential  to  reduce  redundancy  in  code  and  specifications, 
while  enhancing  developer  productivity.  The  confidence  that  comes  with  the  error  checking  in  Plaid’s  state 
model  may  also  help  developers  to  evolve  and  refactor  so  it  ware  with  greater  confidence. 
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In  future  work,  we  plan  to  build  more  programs  with  Plaid  in  order  to  investigate  the  possible  benefits 
outlined  above.  We  are  also  developing  a  gradual  type  system  that  can  complement  Plaid's  dynamic  state 
checking  with  static  checking,  where  desired  by  programmers  [28].  We  believe  Plaid  demonstrates  a  new 
kind  of  language,  and  we  arc  excited  to  explore  the  consequences  that  language  may  entail. 
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Appendices 

A  Unique  members  proof 

Theorem  1:  If  uniqueTags(cwi)  A  ov\  A-  ov 2  =>  ov 3,  then  uniqueTags(or>3). 

Proof:  By  induction  on  ov  1  A-  ov 2  =t>  ov 3. 

Crt.ve  SU-List: 

uniqueTags(ov0)  by  the  induction  hypothesis. 

Case  SU-MV: 

uniqueTags(oiy)  by  assumption. 
uniqueTags(oVi  y  mvu)  by  rule  UniqueTagsOV2. 

Case  SU-AddH: 

uniqueTags(or;t)  by  assumption. 
uniqueTagsfoty  y  mvu)  by  rule  UniqueTagsOV  1 . 

Case  SU-MatchDim: 

uniqueTags(oty)  by  assumption. 
uniqueTags(diy)  by  the  induction  hypothesis. 
uniqueTagsfoi'/,  y  dvr )  by  rule  UniqueTagsOV  1 . 

Case  SU -Matchlnner: 

uniqueTags(£a</{cw}  <:  dv)  by  assumption. 
uniqueTags(oiv)  by  the  induction  hypothesis. 
tag  0  tags  (dv)  A  tag  0  tags(cw)  A  uniqueTags(cfo)  A 
tags(ew)  0  tags(cfo)  =  0  by  inversion  of 
uniqueTags  (tag{cw}  <:  dv). 
tag  $  tags(oty)  by  Lemma  3. 
tags(oiy)  n  tags(cfo)  =  0  by  Lemma  2. 
uniqueTags(fa<7{onr}  <:  dv)  by  rule  UniqueTagsDv. 

Case  SU -MatchSuperlnner : 

tag  0  tags(drv)  by  Lemma  3. 
tags(cw)  n  tags(dry)  =  0  by  Lemma  2. 
uniqueTags  (£ag{cw}  <:  dvr)  by  UniqueTagsDv. 

Case  SU-MatchSuper: 

uniqueTags(diy)  by  the  induction  hypothesis. 

Case  SU-Match: 

uniqueTags(dr;sub  <:  tag{ov}  <:  dv)  by  rule  UniqueTagsDv. 

□ 

Lemma  1:  If  ov\  V-  ov 2  ov 3  then 

tags(<W3)  C  tags(cwi)  U  tags(cw2) 

Proof:  By  easy  induction  on  ov  1  4—  ov 2  =t  ov 3 

□ 

Lemma  2:  If  ov  1  A-  ov 2  ov 3  A 

tags(cw)  n  tags(owi)  =  0  A  tags(on)  n  tags(cw2)  =  0  then  tags(on)  n  tags(cw3)  =  0 
Proof: 
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tags(cw)  n  (tags(ofi)  U  tags(ov2))  =  0 
tags(cws)  C  tags(cwi)  U  tags(<W2)  by  Lemma  1. 
tags(cw)  n  tags(ovs)  =  0 

□ 

Lemma  3:  If  ov\  A-  ov 2  ov 3  A  tag  tags(oni)  A 

tag  0  tags(cw2)  then  tag  0  tags(or>3) 

Proof: 

tag  (tags(cwi)  U  tags(cw2))  =  0 
tags(cw3)  C  tags(oni)  U  tags(cw2)  by  Lemma  1. 
tag  tags (ovf) 

□ 

Theorem  2:  If  we  e@H  i->  e'@H'  and  €  iLuniqueTags(iT[£]),  then  W  G  Lr7.uniqueTags(tf7[T]) 
Proof:  By  induction  on  e@H  i-a  e'@H' 

Case  E-New  and  E-Replace: 

W7  G  H[i  -~?ov]  .uniqueT ags ( H \P] )  by  the  induction  hypothesis  and  rule  premise. 

Case  E-Su: 

un  i  que T ag  s  ( o(;:> )  by  Theorem  1. 

'id  G  H[i  0U3 ] . un i qu e T ag s ( [t7 ] )  by  the  induction  hypothesis. 

All  Other  Rules: 

Heap  does  not  change. 


B  Source  Translation  Rules 

The  rules  in  figures  12  and  13  below  describe  how  to  translate  a  program  written  in  the  Plaid  source  language 
given  in  figure  1 1  to  the  internal  language  defined  in  figure  4. 
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CU  e 

D  oe 

SD  val  s  >  s'  =  se 

S  oe 

TO  to 

groupStates(D) 

groupStates(D)  oe 


-TR-CU 


CU  let  top  =  new  (proto  oe)  in  top.mainQ 

D  oed  SEf  ef  f'  =  freshname  oe'd  =  oed[f'/f] 
val  /  =  SEf,D  val  /  >  /'  =  ef  r  oe'd 

D  oed  SE  e 


TR-DeclField 


method  m(x){SE},  D  method  m(x){e}  r  oed 


-TR-DeclMethod 


D  oed  SD  ■w  val  s  >  s'  =  sd 


-TR-DeclStates 


{SD},D  -w  (recstate{val  s  >  s'  =  proto  sd}  Toed) [s'/s] 

S  oe  s'  =  freshname  S  oe  s'  =  freshname 


-TR-StateTag 


state  s  =  S  val  s  >  s'  =  (proto  freshtagjoe})  val  s  =  S  val  s  >  s'  =  oe 

Ss{TO}  ^  de  S  ^  oe  s'  =  freshname 


TR-StateVal 


state  s  case  of  ss{TO}  =  S  val  s  >  s'  =  (proto  freshtagjoe}  <:  de) 


-TR-StateCase 


groupStates(D)  oe 


{D}  ^  oe 


TR-StateDecl 


Si  ^  oe  i  S2  oe  2  r 

Si  with  S2  ^  oe  1  t  oe 2 


:TR-StateWith 


SE  ^  e 


freez e(SE)  freeze(e' 

{to} 


TR-StateFreeze 


SE^e 


-TR-StateSelect 


s{TO}  s{to} 

val  /  =  SE  val  /  >  /'  =  e 
val  [s.]/  =  SE  [s.](val  /  =  e) 

S  oe 


-TR-StateInit 


SE.s  e.s 

TO  to  TO  to 


-TR-StateName 


-TR-SpecGeneral 


TR-SpecField 


TO,  TO  to,  to 
method  m(x){E}  method  m{x){e} 


method  [s.]m(®){E}  [s.](method  m(x){e}) 

Ir  ,  r  w  -TR-SpecState  - - TR-SpecRemove 

val  [s.]i  =  S  [s.](val  t  =  oe)  \n  -w  \n 

groupStates  (SD',D)  =  {sdi  =  SDi},D'  s  =  name(SE) 


-TR-SpecMethod 


n  — >  n  n  —t  n 


7TR-SpecRename 


groupStates(SE,  SD  ,  D)  =  {s  =  SD,  sdi  =  SDi},  D' 

s  =  nam e(SD)  D  =  ■  V  (D  =  (D,  W)  A  D  ±  SD)  r 
groupStates)^!),  D)  =  {s  =  SD},  groupStates(E) 


TR-GStAdd 


-TR-GStStart 


D^SD 

- = - ^TR-GMember 

groupStates(E,  D)  =  D,  groupStates(E) 


Figure  12:  Translate  Declarations 
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TR-New 


TR-Var 


TR-App 


EE 


e 


C 


'W  C 


S  oe 

new  S  new  oe 


x  x 


SEf  ef  SEa  ea 
SEf(SEa)  e/(e^) 


EEr  er 
SEr.m(SEa ) 


£Ea  ea 
er.m{e^) 


TR-Call 


EE  -w  e 


SE.f 


- TR-Field 

e-/ 


SE  ^  e  S  ^  oe 

- TR-SU 

EE  E  e  <—  oe 


EE  -we  S  ^  oe 

- TR-Replace 

EE  «—  E  e  «-  oe 


let  ,x 


EEX  EEfe  e& 

- TR-Let 

=  SEX  in  SEb  -w  let  x  =  in  eb 


EE  -^e  C  c  EE  e 

- = - TR-Match  - TR-CaseI 

match(EE){C}  match(e){c}  case  s  {EE}  —  case  s  {e} 

SEC  ec  SE  e  EE  ^  e 

- TR-Case2  - TR-Default 

case  SEc.s  {EE}  case  ec.s  {e}  default  {EE}  default  {e} 


Figure  13:  Translate  Expressions 


